Skip site navigation (1)Skip section navigation (2)
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-questions" 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>