Date: Wed, 8 Dec 1999 11:30:55 -0500 From: Greg Lehey <grog@mojave.sitaranetworks.com> To: "Justin T. Gibbs" <gibbs@FreeBSD.ORG> Cc: 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: <19991208113055.01750@mojave.sitaranetworks.com> In-Reply-To: <199912081614.JAA00421@caspian.plutotech.com>; from Justin T. Gibbs on Wed, Dec 08, 1999 at 09:14:32AM -0700 References: <19991207205800.62679@mojave.sitaranetworks.com> <199912081614.JAA00421@caspian.plutotech.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wednesday, 8 December 1999 at 9:14:32 -0700, Justin T. Gibbs wrote: >> 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. With a proper two-phase commit, I could at least know how far I had got and repeat the commit after recovery. But if I remove the commit record before the commit is complete, I'm inconsistent. For the record, Vinum currently doesn't do a two-phase commit. It's a lot of overhead, and I'd have to make it an option. >> 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. > > If the application is bound by write latency, it is not written > properly. Async I/O was developed for a reason. That's a definition. But it doesn't alter the fact that there are a lot of improperly written applications out there. 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?19991208113055.01750>