Why is there no JFS?

[David Schultz]

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
common case.

To Unsubscribe: send mail to majordomo at FreeBSD.org
with "unsubscribe freebsd-questions" in the body of the message