From owner-freebsd-questions Thu Feb 13 12:22:20 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 4215137B401; Thu, 13 Feb 2003 12:22:17 -0800 (PST) Received: from spork.pantherdragon.org (spork.pantherdragon.org [206.29.168.146]) by mx1.FreeBSD.org (Postfix) with ESMTP id C710C43FDD; Thu, 13 Feb 2003 12:22:15 -0800 (PST) (envelope-from dmp@pantherdragon.org) Received: from sparx.techno.pagans (12-224-208-117.client.attbi.com [12.224.208.117]) by spork.pantherdragon.org (Postfix) with ESMTP id 5B2F41005F; Thu, 13 Feb 2003 12:22:14 -0800 (PST) Received: from pantherdragon.org (speck.techno.pagans [172.21.42.2]) by sparx.techno.pagans (Postfix) with ESMTP id B1BB7AB6A; Thu, 13 Feb 2003 12:22:11 -0800 (PST) Message-ID: <3E4BFE74.2000103@pantherdragon.org> Date: Thu, 13 Feb 2003 12:22:12 -0800 From: Darren Pilgrim User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.2.1) Gecko/20030210 X-Accept-Language: en-us, en MIME-Version: 1.0 To: David Schultz Cc: Terry Lambert , Brooks Davis , Matthew Emmerton , Daxbert , Bill Moran , Heinrich Rebehn , freebsd-questions@FreeBSD.ORG, freebsd-fs@FreeBSD.ORG Subject: Re: Why is there no JFS? 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> <20030213191356.GA14560@HAL9000.homeunix.com> In-Reply-To: <20030213191356.GA14560@HAL9000.homeunix.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit 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: > 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. For what its worth, I think all that's needed is to change line 339 in usr.sbin/sysinstall/label.c: --- label.c Mon Dec 30 21:19:15 2002 +++ label.c.new Thu Feb 13 11:50:44 2003 @@ -336,7 +336,7 @@ strcpy(pi->newfs_data.newfs_ufs.user_options, ""); pi->newfs_data.newfs_ufs.acls = FALSE; pi->newfs_data.newfs_ufs.multilabel = FALSE; - pi->newfs_data.newfs_ufs.softupdates = strcmp(mpoint, "/"); + pi->newfs_data.newfs_ufs.softupdates = TRUE; pi->newfs_data.newfs_ufs.ufs2 = FALSE; return pi; The patch is against the 5.0-R tagged version, but it should still apply to the current version. I think softupdates is still (viewed as) riskier than synchronous writes, at least for large numbers of writes (like installworld) to a filesystem of limited size, so someone is going to inevitably ask if FreeBSD should be loading the bullets as well. Personally, if it's a matter of choosing overall safety or a performance gain for something you really shouldn't be doing to a live machine anyway, I'll take the safe route and option the performance gain. P.S., thanks everyone for the discussion, it was enlightening. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-questions" in the body of the message