svn commit: r198316 - head/sbin/tunefs

[Bruce Evans]

On Thu, 22 Oct 2009, Bruce Evans wrote:

> ...
> NetBSD's 2005 version says:
>
> % BUGS
> %      This program should work on mounted and active file systems.  Because 
> the
> %      super-block is not kept in the buffer cache, the changes will only 
> take
> %      effect if the program is run on unmounted file systems.  To change the
> %      root file system, the system must be rebooted after the file system is
> %      tuned.
>
> "mounted and active" is as unclear as "active".  The rotted words about
> rebooting seem to have come from here -- I just noticed that they are
> very recent additions to FreeBSD's tunefs.8.  They were added in 2007
> 8 years after they stopped applying.  Bah, they aren't evem wrong like
> that: allthough they are identical to NetBSD, they have a completely
> different meaning.  In NetBSD they are related to the buffer cache as
> dsecribed above, but in FreeBSD they are a special case for soft updates,
> as described only in their log message.  It takes a full mount to get the
                                            ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> soft updates flag looked at, so the remount done by tunefs doesn't work
   ^^^^^^^^^^^^^^^^^^^^^^^^^^^
> for changes to the soft updates flag.

Actually, ffs_mount(...MNT_UPDATE...) looks at it and seems to partly
work.  I tried it with the file system mounted r/o (had to MNT_UPDATE
from r/w to r/o to run tunefs to test this).  Then MNT_UPDATE from
tunefs didn't give a soft update mount and didn't clear my async mount
flag according to mount(1), but a subsequent MNT_UPDATE to r/w did
(after manually clearing the async flag for safety).  Soft updates
then didn't cause any problems (didn't test enough to see if it really
worked).  Then turning of the soft updates flag using tunefs (after
MNT_UPDATE to r/o) didn't get rid of the soft updates mount after
various remounts.

I think the off->on transition of the soft updates flag is only seen
accidentally by some paths through ffs_mount(...MNT_UPDATE...) and this
transition should be avoided for all MNT_UPDATEs for safety, so tunefs
asking MNT_UPDATE to see it is dangerous.

Bruce