Date: Tue, 7 Dec 1999 20:58:00 -0500 From: Greg Lehey <grog@mojave.sitaranetworks.com> To: "Justin T. Gibbs" <gibbs@FreeBSD.ORG>, Mike Smith <msmith@FreeBSD.ORG>, Matthew Dillon <dillon@apollo.backplane.com> Cc: Julian Elischer <julian@whistle.com>, cvs-committers@FreeBSD.ORG, cvs-all@FreeBSD.ORG Subject: Ordered writes and completion (was: cvs commit: src/sys/kern kern_shutdown.c) Message-ID: <19991207205800.62679@mojave.sitaranetworks.com> In-Reply-To: <199912071504.IAA00354@caspian.plutotech.com>; from Justin T. Gibbs on Tue, Dec 07, 1999 at 08:04:27AM -0700 References: <199912070617.WAA00550@mass.cdrom.com> <199912071504.IAA00354@caspian.plutotech.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tuesday, 7 December 1999 at 8:04:27 -0700, Justin T. Gibbs wrote: >>> Softupdates is pointless without this because Soft Updates cannot >>> guarantee the state of the filesystem to be sane unless the disk does not >>> lie about whether it has written to the disk. >> >> This is kinda immaterial except at completion boundaries. Whether you >> wait for the disk to flush its cache, or mandate that it flushes >> immediately after each transaction, the net result is the same. >> >>> Soft updates also makes all >>> the writes async, so who cares.. :-) >> >> Anyone who cares about the drive's ability to sort outstanding cache line >> writes for optimal throughput. > > Remember that softupdates doesn't care if the drive does write behind so > long as it only acknowledges that the write has completed once the drive > can guarantee it will hit the platters. Usually this means that it has > been written, but it may mean that the head is on cylinder and that the > data can be written (barring a media failure) even if power is lost. > You should get this behavior if you disable write caching on the disk, > and with tagged queuing, the drives firmware should still have plenty > of information to sort how it clears its write buffer. On Tuesday, 7 December 1999 at 10:09:47 -0800, Matthew Dillon wrote: > > I just realized --- softupdates doesn't use the ordered tag at all. > It only issues writes for buffers that can be written out of order, > then waits for the SCSI command to complete before issuing the > dependancies. Does the ordered bit in buffer headers work at all? I can't see how it can work across multiple devices, anyway. This may not be so important with single devices, but with Vinum it's critical. I've stopped using B_ORDERED as a result and am waiting for completion instead. Not the way I'd like to go. On Tuesday, 7 December 1999 at 10:24:28 -0800, Mike Smith wrote: > > It'd be interesting to elide the wait and see if this improved > throughput. It's not (really) much of a safeguard once you assume that > disks/downstream caches are write-buffering things anyway. > > (Making that behaviour default would not be a good idea, but it'd be > interesting to see what impact it might have.) On Tuesday, 7 December 1999 at 14:09:28 -0800, Matthew Dillon wrote: > It would have no impact at all. Softupdates is an asynchronous > mechanism and it is able to parallelize I/O significantly -- for > example, it is fully able to commit 10 data blocks simultaniously, > it is simply that it will not commit the indirect block elements pointing > to those data blocks (recursively) until the data block commit has > completed. I can't quite agree on this. For a large number of similar processes, the throughout probably wouldn't suffer, but latency (response time) obviously would. We could argue the point whether the difference would be noticable, but the difference definitely exists. > I do not assume that disks/downstream caches are returning > completion on the SCSI request prior to the physical write to > the media (or other non-volatile storage) completing. This is > totally unrelated to using ordered or unordered tags. My understanding of the discussion was that this is exactly what they're doing. See Justin's comments at the top of this reply. Greg -- Finger grog@lemis.com for PGP public key See complete headers for address and phone numbers To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe cvs-all" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?19991207205800.62679>