From owner-freebsd-hackers Thu Feb 20 09:15:17 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id JAA24036 for hackers-outgoing; Thu, 20 Feb 1997 09:15:17 -0800 (PST) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.50]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id JAA24028 for ; Thu, 20 Feb 1997 09:15:13 -0800 (PST) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id KAA15408; Thu, 20 Feb 1997 10:10:56 -0700 From: Terry Lambert Message-Id: <199702201710.KAA15408@phaeton.artisoft.com> Subject: Re: [Fwd: Failed mail: unknown user] To: asami@vader.cs.berkeley.edu (Satoshi Asami) Date: Thu, 20 Feb 1997 10:10:56 -0700 (MST) Cc: joerg_wunsch@uriah.heep.sax.de, james@wgold.demon.co.uk, hackers@freebsd.org, dufault@hda.com In-Reply-To: <199702200052.QAA00662@silvia.HIP.Berkeley.EDU> from "Satoshi Asami" at Feb 19, 97 04:52:38 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > * 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. > > Really? I think drives have their own cache, and if they have write > buffering turned on, they will happily return "write complete" when > they are only holding data in the buffer. In general, this is a track buffer, if it exists at all, and the premature return is contingent on the momentum of the disk being able to power the disk to do the write. The drive isn't permitted to lie... if it says the write made it to stable storage, it either did, or will. The one window for error here is if it gets a write error, and the drive is out of replacement sectors, making the error unrecoverable (in the general case) or if it has a write error, and the replacement of the affected area would require a seek (and the drive does not have enough momentum to both power the write and to run the voice coil to move the heads -- or it does, but the replacements are bad too). If you want guarantees, it can't be on, or you must do read-after- write after the flush timeout. > I know Seagate ST15150WC (old Barracuda 4) had the write buffer > disabled, while Quantum 34300WC (Atlas 4) had it enabled. If you > really want to make sure you write through to the platter, either get > one of those that don't have it turned on or turn it off by youself > (I heard it's in one of the SCSI mode pages). For the ones that support it, it is (at least the one I had had this). I don't think any drive supports it which does not power the writes in case of supply failure. Regards, Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.