Path: utzoo!utgpu!attcan!uunet!seismo!sundc!pitstop!sun!pope@vatican From: pope@vatican (John Pope) Newsgroups: comp.unix.wizards Subject: Write-Behind (was Re: Record-access libraries) Message-ID: <74161@sun.uucp> Date: 23 Oct 88 05:35:37 GMT References: <287@cvbnet2.UUCP> <107@minya.UUCP> <931@riddle.UUCP> Sender: news@sun.uucp Reply-To: pope@vatican (John Pope) Organization: Sun Microsystems, Inc. Lines: 57 In-reply-to: domo@riddle.UUCP (Dominic Dunlop) In article <931@riddle.UUCP>, domo@riddle (Dominic Dunlop) writes: >In article <107@minya.UUCP> jc@minya.UUCP (John Chambers) writes: >> >>[...] According to several >>manuals, the main difference between /dev/dsk* and /dev/rdsk* is that >>there is no buffering for the latter. Reads always delay for physical >>I/O, and writes always go immediately to disk (though with DMA, the >>write may not be complete when write() returns). > > Worse, the disk controller hardware may be ``intelligent'', buffering write > data in its private memory for an indeterminate time before actually > writing it onto the physical disk medium. I agree, this is worse. Since the controller doesn't discriminate between raw and filesystem I/O, it will do "write-behind" in the filesystem case as well. This could lead to the controller saying the I/O is done when it really isn't, which could in turn lead to filesystem integrity problems if the system should crash. Although such integrity problems already exist, doing write-behind on the controller exacerbates the situation, as you now have a race between writing updated filesystem control information and actually writing the block the controller already told you it wrote. 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. > UNIX System V, release 3 and later (but not the POSIX standard, IEEE > 1003.1, or, as an example of a BSD-derived system, SunOS) has a > synchronous write facility (enabled with the O_SYNC flag... FYI, the latest version of SunOS (4.0) does have O_SYNC. > This is where I get to admit my ignorance: 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 ?? > One thing that makes me think that the problem may still be around is > this: there has been recent discussion elsewhere about the ability to do > single byte reads and writes to raw disks on certain computers. Hmmm. > Sounds as though the controllers have their own buffers, doesn't it? I haven't seen the discussion, but it sounds like they are targeted towards database or other systems where doing a quick single byte read-modify-write cycle on the raw device is common enough to make a special case for it. I don't think this necessarily involves write-behind, though... >-- > Dominic Dunlop > domo@sphinx.co.uk domo@riddle.uucp John Pope Sun Microsystems, Inc. pope@sun.COM