Date: Wed, 12 Feb 2003 23:17:15 -0800 From: Terry Lambert <tlambert2@mindspring.com> To: David Schultz <dschultz@uclink.Berkeley.EDU> Cc: Brooks Davis <brooks@one-eyed-alien.net>, Darren Pilgrim <dmp@pantherdragon.org>, 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: <3E4B467B.4DCF6D5@mindspring.com> References: <3E4A8EF5.1070308@ant.uni-bremen.de> <3E4A9712.8030609@potentialtech.com> <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> <3E4ADDDE.5040208@pantherdragon.org> <3E4B138F.26E32E75@mindspring.com> <20030212210721.A9481@Odin.AC.HMC.Edu> <20030213051952.GA11572@HAL9000.homeunix.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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. -- Terry 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?3E4B467B.4DCF6D5>