Date: Thu, 22 Jun 2000 11:54:26 +0200
        From: Adrian Chadd <[EMAIL PROTECTED]>
        Subject: Re: cvs commit: src/sys/contrib/softupdates softdep.h

        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 ?


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]>
                Stefan Esser <[EMAIL PROTECTED]>
        Subject: Re: cvs commit: src/sys/contrib/softupdates softdep.h


        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

Reply via email to