Skip site navigation (1)Skip section navigation (2)
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>