Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.1 6/24/83; site watrose.UUCP
Path: utzoo!watmath!watrose!dmmartindale
From: dmmartindale@watrose.UUCP (Dave Martindale)
Newsgroups: net.bugs.4bsd
Subject: Re: 4.2BSD installation mystery ...
Message-ID: <118@watrose.UUCP>
Date: Fri, 9-Dec-83 15:39:39 EST
Article-I.D.: watrose.118
Posted: Fri Dec  9 15:39:39 1983
Date-Received: Sat, 10-Dec-83 06:58:58 EST
References: <2397@azure.UUCP>
Organization: U of Waterloo, Ontario
Lines: 24

In ALL versions of UNIX that I know of, the kernel has no idea of any
sort of correspondence between disk blocks accessed via the "block"
and "character"/"raw" devices.  They are completely different interfaces
as far as the system is concerned, and there is no locking of updates
between them.  References to the "raw" device ALWAYS read/write data
directly from disk to memory or vice versa; references to the "block"
device always go through the buffer cache.  If you do a write on the
block device, doing a sync will ensure that it has been written out and
so it will be there for any subsequent reads of either device.  But if
a particular block is already in the buffer cache, there is no way of
convincing the kernel that it is an invalid copy of the disk data after
you've written the block using the raw device.  Thus, reads of that block
using the block interface will give you the old data as long as the
block remains in the cache.

Yet another effect is that most versions of UNIX keep the superblock
of a mounted filesystem in a secret buffer in memory, that is not part
of the buffer cache.  If you update the superblock in the cache with
the block device interface, you still haven't updated the superblock
that the kernel deals with.  The only way you can safely fsck a filesystem
is with it NOT MOUNTED - then the kernel doesn't have the secret copy.
4.1BSD did not have this problem, but it seems to be back in 4.2BSD.

	Dave Martindale