Write-Behind (was Re: Record-access libraries)

[Chris Torek]

In article <74161 at sun.uucp> pope at vatican [indeed!] (John Pope) writes:
>[such a controller] will do "write-behind" in the filesystem case
>as well. This could lead to ...  filesystem integrity problems if
>the system should crash.

For whatever reasons, some hardware manufacturers either never think
of this, or else do it and keep quiet about it anyway.

>It's unclear that such a scheme buys you much anyway, since the kernel
>already does "write-behind" for filesystem I/O (unless, as you point
>out, the O_SYNC flag is set), while if you're working on the raw disk,
>your application will probably want to control the data buffering itself.

Not all kernels have buffering.  VMS, for instance, does not (at the
ODS-II level: RMS does its own buffering and no doubt uses ASTs and
such).  Why do you think DEC thought the 16 kB in the UDA50 was such a
wonderful buffer?  (Maybe it was 32k, but anyway, small enough not to
matter---it does not even buffer one track of an RA81.) (It is always
amusing to watch the reaction of salespersons when you tell them that
your machine already uses over a megabyte of buffering, and their 64k
is not interesting.)

>>... maybe five years ago, intelligent controllers which defeated the
>>``write straight to disk'' characteristic of raw devices were
>>dismayingly commonplace.  

>Which ones? The UDA-50 didn't do this, did it #:-o ??

No, it does not report the transfer as done until it has in fact been
written.  It *may* reorder writes, however (it is hard to tell for sure).
-- 
In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163)
Domain:	chris at mimsy.umd.edu	Path:	uunet!mimsy!chris