Date: Fri, 24 Sep 2004 15:53:26 -0000 From: David Schultz <dschultz@uclink.berkeley.edu> To: dwbear75@gmail.com Cc: freebsd-questions@FreeBSD.ORG Subject: Re: Why is there no JFS? Message-ID: <20030213074449.GA12084@HAL9000.homeunix.com> In-Reply-To: <3E4B467B.4DCF6D5@mindspring.com> 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> <3E4B138F.26E32E75@mindspring.com> <20030212210721.A9481@Odin.AC.HMC.Edu> <3E4B467B.4DCF6D5@mindspring.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Thus spake Terry Lambert <tlambert2@mindspring.com>: > David Schultz wrote: > > > There's no chicken and egg problem when you're booting off install > > > media or for that matter from single user mode. The problem was that > > > softupdates means you don't get space back from deleted files immediatly > > > so previously / tended to fillup during installworld or installkernel. > > > I know some fixes have been implemented in that area, but I'm not sure > > > if then mean you can always write to the space occupied by unlinked > > > files or just that you have a better chance. > > > > The problem is effectively fixed in 5.0. Basically, when no space > > can be found, the syncer is accelerated to try to speed up frees. > > Technically it's possible to run into a livelock, where you keep > > freeing space and it keeps getting snatched up before you can grab > > it, so you wait forever. So IIRC, there is a point where it just > > gives up on finding the space. However, that won't happen with an > > install, so the free space problem isn't a reason not to use > > softupdates on the root FS. I think the default hasn't been > > changed just because nobody has bothered. > > 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. 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?20030213074449.GA12084>