From owner-freebsd-fs Thu Feb 13 11:14:26 2003 Delivered-To: freebsd-fs@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 780CB37B401; Thu, 13 Feb 2003 11:14:23 -0800 (PST) Received: from HAL9000.homeunix.com (12-233-57-224.client.attbi.com [12.233.57.224]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6BC5743FA3; Thu, 13 Feb 2003 11:14:22 -0800 (PST) (envelope-from dschultz@uclink.Berkeley.EDU) Received: from HAL9000.homeunix.com (localhost [127.0.0.1]) by HAL9000.homeunix.com (8.12.6/8.12.5) with ESMTP id h1DJE5Dm014593; Thu, 13 Feb 2003 11:14:05 -0800 (PST) (envelope-from dschultz@uclink.Berkeley.EDU) Received: (from das@localhost) by HAL9000.homeunix.com (8.12.6/8.12.5/Submit) id h1DJDujj014592; Thu, 13 Feb 2003 11:13:56 -0800 (PST) (envelope-from dschultz@uclink.Berkeley.EDU) Date: Thu, 13 Feb 2003 11:13:56 -0800 From: David Schultz To: Terry Lambert 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? Message-ID: <20030213191356.GA14560@HAL9000.homeunix.com> Mail-Followup-To: Terry Lambert , Brooks Davis , Darren Pilgrim , Matthew Emmerton , Daxbert , Bill Moran , Heinrich Rebehn , freebsd-questions@FreeBSD.ORG, freebsd-fs@FreeBSD.ORG References: <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> <3E4BA1D2.E259308@mindspring.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3E4BA1D2.E259308@mindspring.com> Sender: owner-freebsd-fs@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Thus spake Terry Lambert : > 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. My point was that a busy disk that is nearly 100% full will probably experience intermitted ``disk full'' errors anyway, so it suffices to simply deal with cases such as 'rm -rf foo && immediately create lots more files', which softupdates does handle in -CURRENT. > 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. The original reason was due to the possibility of installworld failing, due to the case described above not being handled particularly well in FreeBSD 4.X. Sysinstall is perfectly happy with creating a root FS with softupdates enabled. If someone wants to bother changing the default for what little difference it might make in installworld/installkernel times, I would support it. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message