From owner-freebsd-current Sat May 20 10:31:15 2000 Delivered-To: freebsd-current@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by hub.freebsd.org (Postfix) with ESMTP id DB94E37B6C7 for ; Sat, 20 May 2000 10:31:12 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id KAA45787; Sat, 20 May 2000 10:31:06 -0700 (PDT) (envelope-from dillon) Date: Sat, 20 May 2000 10:31:06 -0700 (PDT) From: Matthew Dillon Message-Id: <200005201731.KAA45787@apollo.backplane.com> To: Greg Lehey Cc: Matthew Reimer , current@FreeBSD.ORG Subject: Re: Possible Vinum RAID-5 problems? (was: panic: ffs_valloc: dup alloc) References: <39256530.1FD33AA5@vpop.net> <200005191943.MAA40388@apollo.backplane.com> <20000520124936.E57670@freebie.lemis.com> Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :> Wait a sec... softupdates does not depend on write ordering. :> Softupdates issues all non-conflicting writes in parallel and :> doesn't care what order they are written to the disk. When :> those complete, softupdates will then followup with all the :> writes that depend on the original set. : :Hmm. Maybe I've misunderstood, then. It was my understanding that :soft updates writes metadata with WRITE_ORDERED set, and thus avoids :having to explicitly wait for completion. It's the WRITE_ORDERED that :Vinum doesn't handle correctly. On a single disk, it's just a :question of not sorting around a WRITE_ORDERED request. Vinum will :keep the WRITE_ORDERED on a single disk, but it won't ensure that a :request for the same volume, but which is destined for a different :disk, will not be written until after all components of a prior :WRITE_ORDERED request for that volume. : :Greg Softupdates does not use bowrite(). In fact, the only place anyone uses bowrite() is in the UFS directory code, and if softupdates is turned on even those few bowrite()s are turned *OFF*. Softupdates is very strict in how it issues I/O. There are two cases. In the normal case softupdates does not issue dependant I/O until the I/O associated with the dependancy itself completes. In the second case, where the kernel forces a buffer to be flushed, softupdates will issue I/O on a non-dependant version of the buffer and then redirty the buffer with the dependant data. -Matt Matthew Dillon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message