Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.1 (Tek) 9/26/83; site azure.UUCP
Path: utzoo!linus!decvax!tektronix!azure!stevesu
From: stevesu@azure.UUCP (Steve Summit)
Newsgroups: net.bugs.4bsd
Subject: Re: 4.2BSD installation mystery ...
Message-ID: <2397@azure.UUCP>
Date: Mon, 5-Dec-83 23:33:06 EST
Article-I.D.: azure.2397
Posted: Mon Dec  5 23:33:06 1983
Date-Received: Fri, 9-Dec-83 00:27:23 EST
References: <184@rna.UUCP>
Organization: Tektronix, Beaverton OR
Lines: 25

I occasionally had bizarre problems like this when working on a
2.8 system.  I would fsck the raw interface, and the block
interface would still be broken, and vice versa.  df's on the two
interfaces could show differend free block counts, etc. 
restoring to one interface and fsck-ing the other could wipe out
the restor.

My hunch (never verified, I just learned to use one interface
consistently) was that the kernel was getting confused on block
caching (particularly the superblock), not realizing that a block
from /dev/??? was the same as a block from /dev/r???.  Suppose a
block from /dev/??? was modified, but not written out.  A
subsequent read of the same block from /dev/r??? might go
directly to disk, not realizing that the modified block was in
core, and get an obsolete version.

The only flaw in this reasoning is that I have this memory that
doing a sync between the write to one device and the read from
the other didn't necessarily help...

Can anyone confirm or deny this supposition of mine?  If it's
true, there should be some warning about it in the documentation.

                                         Steve Summit
                                         tektronix!tekmdp!stevesu