Date: Mon, 22 Feb 1999 05:34:08 +0000 (GMT) From: Terry Lambert <tlambert@primenet.com> To: dfr@nlsystems.com (Doug Rabson) Cc: tlambert@primenet.com, dillon@apollo.backplane.com, freebsd-hackers@FreeBSD.ORG Subject: Re: Panic in FFS/4.0 as of yesterday Message-ID: <199902220534.WAA01171@usr07.primenet.com> In-Reply-To: <Pine.BSF.4.05.9902210943270.82049-100000@herring.nlsystems.com> from "Doug Rabson" at Feb 21, 99 09:47:16 am
next in thread | previous in thread | raw e-mail | index | archive | help
> > > I think promoting directory writes (and directory reads probably) might be > > > the simplest solution. > > > > OK, here's code to add the ability to expedite placement of async > > writes. It' doesn't insert them in order behind other expedited > > writes, so it turns the expedited stuff LIFO. This is probably > > suboptimal, but can't happen in dependent operations, so what the > > heck... > > > > When you use the code, be sure to *not* set the flag if soft updates > > are in effect (I think that's a caller issue, not a callee issue, since > > it would complicate the bdwrite code, probably unacceptably. > > I don't think this will do the job at all. The buffers in question are > not delayed writes, so all this patch will do is change the order of the > LOCKED and LRU lists, probably pessimising the reuse of those buffers. Check the code paths and look for B_ASYNC getting unset. I believe this is the correct patch. > I think the flag needs to be implemented in the driver. The driver should > check for the EXPEDITE flag and either maintain two queues for the two > possible priorities or place the buffer at the front of a single work > queue. This has some serious flaws. The first is, you have to get it right in more than one driver. This is really like the "wakeup" character change I did to the serial drivers to allow for unanticipated "hotchar" in binary only drivers from third parties, like E.T. Inc.. The second is that the lock cascade occurs because of locked vnodes over an operation queued through this code, and only completion notification will get rid of the lock. The third is that, however you do it, it needs to be harmless to disk integrity in the soft updates and standard mount cases. The standard mount case comes for free, by not using the B_ASYNC flag; but the soft updates case is harder. You won't be able to add an assert check at the queue-to-driver level to make sure the code is right, since the buffer is no longer associated with the structure that contains the soft dependency active/inactive information. Look at the cases where the I/O call is actually made in the UFS code, and trace the function calls down. I'm willing to be wrong. 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?199902220534.WAA01171>