From owner-cvs-all Wed Dec 8 8:31: 7 1999 Delivered-To: cvs-all@freebsd.org Received: from mojave.sitaranetworks.com (mojave.sitaranetworks.com [199.103.141.157]) by hub.freebsd.org (Postfix) with ESMTP id 94F7A14D12; Wed, 8 Dec 1999 08:30:59 -0800 (PST) (envelope-from grog@mojave.sitaranetworks.com) Message-ID: <19991208113055.01750@mojave.sitaranetworks.com> Date: Wed, 8 Dec 1999 11:30:55 -0500 From: Greg Lehey To: "Justin T. Gibbs" Cc: Mike Smith , Matthew Dillon , Julian Elischer , cvs-committers@FreeBSD.ORG, cvs-all@FreeBSD.ORG Subject: Re: Ordered writes and completion (was: cvs commit: src/sys/kern kern_shutdown.c) Reply-To: Greg Lehey References: <19991207205800.62679@mojave.sitaranetworks.com> <199912081614.JAA00421@caspian.plutotech.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii In-Reply-To: <199912081614.JAA00421@caspian.plutotech.com>; from Justin T. Gibbs on Wed, Dec 08, 1999 at 09:14:32AM -0700 Sender: owner-cvs-all@FreeBSD.ORG Precedence: bulk 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