From owner-freebsd-hackers Tue Feb 23 13:26: 6 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from smtp04.primenet.com (smtp04.primenet.com [206.165.6.134]) by hub.freebsd.org (Postfix) with ESMTP id BA44A1141B for ; Tue, 23 Feb 1999 13:25:58 -0800 (PST) (envelope-from tlambert@usr06.primenet.com) Received: (from daemon@localhost) by smtp04.primenet.com (8.8.8/8.8.8) id OAA10417; Tue, 23 Feb 1999 14:46:52 -0700 (MST) Received: from usr06.primenet.com(206.165.6.206) via SMTP by smtp04.primenet.com, id smtpd010258; Tue Feb 23 14:46:45 1999 Received: (from tlambert@localhost) by usr06.primenet.com (8.8.5/8.8.5) id OAA13140; Tue, 23 Feb 1999 14:25:24 -0700 (MST) From: Terry Lambert Message-Id: <199902232125.OAA13140@usr06.primenet.com> Subject: Re: Panic in FFS/4.0 as of yesterday To: dfr@nlsystems.com (Doug Rabson) Date: Tue, 23 Feb 1999 21:25:24 +0000 (GMT) Cc: julian@whistle.com, Don.Lewis@tsc.tdk.com, tlambert@primenet.com, dillon@apollo.backplane.com, freebsd-hackers@FreeBSD.ORG In-Reply-To: from "Doug Rabson" at Feb 23, 99 08:50:57 am X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > softupdates already "kinda" doesn this.. > > it queues data writes at one point in the future and directory writes > > at a different point in the future. I believe that data writes must be > > completed before inode writes which must be completed before directory > > writes. If they are not the the dependencies will FORCE that ordering. > > > > The reason to preschedule the different actions is to make it all happen > > in the right order anyhow, so that the dependency tracking is a big NOP. > > I think softupdates will be less affected by this but there can still be > problems with latency. The time for a simple directory read (not a > softupdate controlled operation) can be delayed significantly since it > gets queued behind all the rest of the async i/o. In Matt's test, I saw > about 5Mb queued at one point which translates to a latency of over > 0.5sec, assuming the drive throughput is about 8Mb/sec. Soft updates is still vulnerable to this, though directory operations are promoted forward, they are not grouped forward, so one set of file I/O can find itself in front of a set of (unrelated) directory I/O. I think the dangers are lessened by "clocking it forward", however; the worst interference is a process with itself, after queueing a tremendous amount of normal I/O before engaging in directory operations. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message