From owner-freebsd-questions Thu Feb 13 5:48:38 2003 Delivered-To: freebsd-questions@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id AD5D337B401; Thu, 13 Feb 2003 05:48:36 -0800 (PST) Received: from stork.mail.pas.earthlink.net (stork.mail.pas.earthlink.net [207.217.120.188]) by mx1.FreeBSD.org (Postfix) with ESMTP id A1C1043F93; Thu, 13 Feb 2003 05:48:35 -0800 (PST) (envelope-from tlambert2@mindspring.com) Received: from pool0013.cvx22-bradley.dialup.earthlink.net ([209.179.198.13] helo=mindspring.com) by stork.mail.pas.earthlink.net with asmtp (SSLv3:RC4-MD5:128) (Exim 3.33 #1) id 18jJj2-0005gR-00; Thu, 13 Feb 2003 05:48:29 -0800 Message-ID: <3E4BA1D2.E259308@mindspring.com> Date: Thu, 13 Feb 2003 05:46:58 -0800 From: Terry Lambert X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: David Schultz Cc: Brooks Davis , Darren Pilgrim , Matthew Emmerton , Daxbert , Bill Moran , Heinrich Rebehn , freebsd-questions@FreeBSD.ORG, freebsd-fs@FreeBSD.ORG Subject: Re: Why is there no JFS? References: <3E4AA331.5040701@ant.uni-bremen.de> <3E4AA734.5040102@potentialtech.com> <045401c2d2db$f9d45c30$0a0aa8c0@dweebsoft.com> <20030212225631.GA10375@HAL9000.homeunix.com> <005801c2d2eb$aa5fae60$1200a8c0@gsicomp.on.ca> <3E4ADDDE.5040208@pantherdragon.org> <3E4B138F.26E32E75@mindspring.com> <20030212210721.A9481@Odin.AC.HMC.Edu> <20030213051952.GA11572@HAL9000.homeunix.com> <3E4B467B.4DCF6D5@mindspring.com> <20030213074449.GA12084@HAL9000.homeunix.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-ELNK-Trace: b1a02af9316fbb217a47c185c03b154d40683398e744b8a4b70f6dcc777bb869f38f81420dc3e403666fa475841a1c7a350badd9bab72f9c350badd9bab72f9c Sender: owner-freebsd-questions@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG David Schultz wrote: > > The easy way to fix this is to insert a new dependency for the > > completion of the allocation. Basically, this would put in a > > stall barrier that would cause the outstanding I/O to drain before > > the new I/O was attempted. All other operations behind the one > > that caused the stall would b held off, which would avoid the > > starvation deadlock you describe. Most likely, all this would > > require some minor code to maintain a running tally of virtual vs. > > real free block count. > > It really isn't a big deal. You're saying you can fix the problem > where allocations can sometimes fail on a busy 99% full > filesystem, but on such a filesystem, you're just as likely to hit > it when it's 100% full. Kirk's solution is simple and has the > advantage of not requiring additional dependency tracking for the > common case. No, actually it should work for "100% full", as well, as long as that "100% full" is "the real disk" vs. "the real disk, after all pending updates have been applied". In other words, if it would have worked with soft updates turned off, then it will work with soft updates turned on. I agree that it's not that big a deal, but if that's truly the current excuse for not having soft updates on for the root FS, this removes all pretense for that excuse. IMO, this is not the reason for them being off on /; the real reason is as I've stated: sysinstall expects the common case to be an initial install, not operations after the initial install, and so does not turn it on by default. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-questions" in the body of the message