Date: Thu, 13 Feb 2003 12:22:12 -0800 From: Darren Pilgrim <dmp@pantherdragon.org> To: David Schultz <dschultz@uclink.Berkeley.EDU> Cc: Terry Lambert <tlambert2@mindspring.com>, Brooks Davis <brooks@one-eyed-alien.net>, Matthew Emmerton <matt@gsicomp.on.ca>, Daxbert <daxbert_news@dweebsoft.com>, Bill Moran <wmoran@potentialtech.com>, Heinrich Rebehn <rebehn@ant.uni-bremen.de>, freebsd-questions@FreeBSD.ORG, freebsd-fs@FreeBSD.ORG Subject: Re: Why is there no JFS? Message-ID: <3E4BFE74.2000103@pantherdragon.org> In-Reply-To: <20030213191356.GA14560@HAL9000.homeunix.com> 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>
next in thread | previous in thread | raw e-mail | index | archive | help
David Schultz wrote:
> Thus spake Terry Lambert <tlambert2@mindspring.com>:
>
>>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-fs" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3E4BFE74.2000103>