Date: Tue, 23 Feb 1999 21:25:24 +0000 (GMT) From: Terry Lambert <tlambert@primenet.com> To: dfr@nlsystems.com (Doug Rabson) Cc: julian@whistle.com, Don.Lewis@tsc.tdk.com, tlambert@primenet.com, dillon@apollo.backplane.com, freebsd-hackers@FreeBSD.ORG Subject: Re: Panic in FFS/4.0 as of yesterday Message-ID: <199902232125.OAA13140@usr06.primenet.com> In-Reply-To: <Pine.BSF.4.05.9902230847020.60339-100000@herring.nlsystems.com> from "Doug Rabson" at Feb 23, 99 08:50:57 am
next in thread | previous in thread | raw e-mail | index | archive | help
> > 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199902232125.OAA13140>