From owner-freebsd-hackers Wed Feb 19 13:52:13 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id NAA21330 for hackers-outgoing; Wed, 19 Feb 1997 13:52:13 -0800 (PST) Received: from sax.sax.de (sax.sax.de [193.175.26.33]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id NAA21314 for ; Wed, 19 Feb 1997 13:52:05 -0800 (PST) Received: (from uucp@localhost) by sax.sax.de (8.6.12/8.6.12-s1) with UUCP id WAA16653; Wed, 19 Feb 1997 22:51:43 +0100 Received: (from j@localhost) by uriah.heep.sax.de (8.8.5/8.6.9) id WAA23697; Wed, 19 Feb 1997 22:35:44 +0100 (MET) Message-ID: Date: Wed, 19 Feb 1997 22:35:44 +0100 From: j@uriah.heep.sax.de (J Wunsch) To: james@wgold.demon.co.uk (James Mansion) Cc: hackers@FreeBSD.ORG Subject: Re: [Fwd: Failed mail: unknown user] References: <330AE27F.7159@wgold.demon.co.uk> X-Mailer: Mutt 0.55-PL10 Mime-Version: 1.0 X-Phone: +49-351-2012 669 X-PGP-Fingerprint: DC 47 E6 E4 FF A6 E9 8F 93 21 E0 7D F9 12 D6 4E Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: <330AE27F.7159@wgold.demon.co.uk>; from James Mansion on Feb 19, 1997 11:22:39 +0000 Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk As James Mansion wrote: > Assume that I'm using a raw device and I set it up so that > I flush through the caches. Raw devices (i.e., really *raw* ones, /dev/rsd0e or something, not just /dev/sd0e) don't go through the buffer cache. They call physio(9), which sets up a buffer header, calls the strategy function of the driver, and waits for the buffer's completion. > - if the OS tells me it has a successful write through the > disk device, can I rely on: > > a) the data is on the platter It is. Since physio(9) waits for the completion, you should be notified of any lower-level errors. Note that this is _unlike_ with the block devices, where writing happens asynchronously, so the kernel did already declare the write operation as successful by the time it notices an error. > - if the system crashes during the write (literally, while > the drive is writing to the platter) can I: ...rely on whatever your drive vendor will tell you. :-) The OS cannot know it then. It has just set up the SCSI command for the operation, and is about (or has done) sending it to the drive. Normally, the drive disconnects, looks up the spot, and later reconnects to the SCSI bus, in order to request the data. (Disclaimer: that's how i understand it, and probably simplified.) Since your supposed power fault can happen any time there, it's uncertain what happens. Needless to say, by using this method you might be safe, but you're slow. You can't benefit from fancy stuff like tagged command queuing (unless there are other operations on the same disk happening simultaneously). -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-)