Why is there no JFS?
dschultz at uclink.berkeley.edu
Fri Sep 24 08:53:26 PDT 2004
Thus spake Terry Lambert <tlambert2 at 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
To Unsubscribe: send mail to majordomo at FreeBSD.org
with "unsubscribe freebsd-questions" in the body of the message
More information about the freebsd-fs