Date: Wed, 08 Dec 1999 09:14:32 -0700 From: "Justin T. Gibbs" <gibbs@FreeBSD.org> To: Greg Lehey <grog@lemis.com> Cc: "Justin T. Gibbs" <gibbs@FreeBSD.ORG>, Mike Smith <msmith@FreeBSD.ORG>, Matthew Dillon <dillon@apollo.backplane.com>, Julian Elischer <julian@whistle.com>, cvs-committers@FreeBSD.ORG, cvs-all@FreeBSD.ORG Subject: Re: Ordered writes and completion (was: cvs commit: src/sys/kern kern_shutdown.c) Message-ID: <199912081614.JAA00421@caspian.plutotech.com> In-Reply-To: Your message of "Tue, 07 Dec 1999 20:58:00 EST." <19991207205800.62679@mojave.sitaranetworks.com>
next in thread | previous in thread | raw e-mail | index | archive | help
>Does the ordered bit in buffer headers work at all? Yes. It guarantees the order of writes to a particular device. >I can't see how it can work across multiple devices, anyway. This was never the intention of the bit. There is no practical method for providing global serialization in any way that is as efficient as what an application can provide. >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. I don't see how a fully ordered system does anything for you. Unless you are using parity verification on reads or embedding a version number in each sub-component block you write, you are still open to having one or more components fail to a write that has been seen by other components. >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 pointin >g >> 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. If the application is bound by write latency, it is not written properly. Async I/O was developed for a reason. >> 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. If you have WCE enabled, then the drives may return completion as soon as the data has been received into their cache. -- Justin 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?199912081614.JAA00421>