Date: Thu, 22 Jun 2000 11:54:26 +0200
From: Adrian Chadd <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Subject: Re: cvs commit: src/sys/contrib/softupdates softdep.h
ffs_softdep.c
On Thu, Jun 22, 2000, Brad Knowles wrote:
> At 10:30 AM +0200 2000/6/22, Adrian Chadd wrote:
>
> > I like this. Would anyone object if this was brought over
> > from NetBSD ?
>
> If you're asking for a vote, you've got mine.
Hmm, Kirk has valid points for leaving a softupdates
filesystem identified by tunefs and not a mount option.
Kirk, do you still want to keep things that way ?
Adrian
Yes, I do want it kept as a yunefs option.
Date: Thu, 22 Jun 2000 13:31:29 +0200
From: Stefan Esser <[EMAIL PROTECTED]>
To: Adrian Chadd <[EMAIL PROTECTED]>
Cc: [EMAIL PROTECTED], [EMAIL PROTECTED],
Stefan Esser <[EMAIL PROTECTED]>
Subject: Re: cvs commit: src/sys/contrib/softupdates softdep.h
ffs_softdep.c
...
I do remember the discussion that lead to the requirement
to enable soft-updates with tunefs -n.
But I do not remember, why the soft-updates state could
not be just set in the local copy of the super-block and
flushed to disk when the file system is marked dirty ?
Just before a clean file system is to be mounted R/W, it
is obviously safe to modify the soft-updates state.
The file system must have been cleaned before, or the R/W
mount will not be possible (extra logic can prevent the
modification of the MNT_SOFTDEP bit if a mount of a non-clean
partition is forced, in order to preserve the soft-updates
state for the next fsck run).
If the kernel was compiled without soft-updates, it may be
the right thing to keep MNT_SOFTDEP cleared, to not mislead
FSCK ...
Did I miss something obvious ?
Regards, STefan
Your above proposal would work, though that is not how NetBSD
implemented it. I feel that it is a lot of extra mechanism for very
little gain. Administrators generally make a one-time decision to
run soft updates on a filesystem. It is not the sort of thing that
they want to change on a regular basis. It is possible to run tunefs
on a filesystem that is mounted read-only, so it no more difficult
to use tunefs than it is to make it a mount-time option (i.e., they
still have to down-grade to read-only, set the option, then upgrade).
Finally, I expect that soft updates will eventually just be defaulted
to `on' when a filesystem is built, and in a few rare instances an
administrator will want to turn it off. I do not want to have an
option that needs to be added to nearly every fstab entry to get
the default behavior. Plus it is just one more bit of trivia that
new system administrators need to learn to make their systems run
well. The more of those details that need not be learned because
they just do the right thing, the better.
Kirk McKusick
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
