Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!csd4.csd.uwm.edu!bionet!ames!sgi!calcite!vjs
From: vjs@calcite.UUCP (Vernon Schryver)
Newsgroups: comp.unix.i386
Subject: Re: ESDI controller recommendations
Message-ID: <72@calcite.UUCP>
Date: 4 Sep 89 20:14:17 GMT
References: <121@mdi386.UUCP> <1474@wb3ffv.ampr.org> <4843@looking.on.ca> <1125@virtech.UUCP>
Organization: Rhyolite Software, Mountain View, CA
Lines: 21

In article <1125@virtech.UUCP>, cpcahil@virtech.UUCP (Conor P. Cahill) writes:
> 
> Raw device support is not provided by the kernel, it is provided by the
> device driver.  Sometimes it makes sense for both the raw interface and
> block interface to both pass through the buffer cache, but for disk i/o
> all device drivers *should* not pass the raw i/o through the cache.  If 
> they did, fsck would have lots of trouble (especially when it told you 
> to reboot-no sync).
> | Conor P. Cahill     uunet!virtech!cpcahil      	703-430-9247	!
> | Virtual Technologies Inc.,    P. O. Box 876,   Sterling, VA 22170     |

Running fsck thru the buffer cache helps.  You don't suffer some of the
inconsistencies that otherwise occur.  Most of the need for the "reboot-no
sync" message goes away.  (BTW, in SVR3 for separate reasons, fsck does not
say that; it automatically re-mounts root.)  As long as the character
device reads & writes the correct bytes quickly, what does it matter to a
user process such as fsck how the driver (which many consider part of the
SVR3 kernel, even if it need not be in MACH) does its thing?

Vernon Schryver
vjs@calcite.uucp    or   ...{sgi,pyramid}!calcite!vjs