Re: Why is there no JFS?

[Darren Pilgrim]

David Schultz wrote:

Thus spake Terry Lambert <[EMAIL PROTECTED]>:

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 [EMAIL PROTECTED]
with "unsubscribe freebsd-questions" in the body of the message