4.2BSD installation mystery ...

Steve Summit stevesu at azure.UUCP
Tue Dec 6 14:33:06 AEST 1983


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



More information about the Comp.bugs.4bsd.ucb-fixes mailing list