svn commit: r198316 - head/sbin/tunefs

[Bruce Evans]

On Wed, 21 Oct 2009, Andriy Gapon wrote:

> on 21/10/2009 14:28 Ivan Voras said the following:
>> 2009/10/21 Remko Lodder <remko at freebsd.org>:
>>> Log:
>>>  The tunefs utility does not work on active filesystems.
>>
>>>  .Sh BUGS
>>> -This utility should work on active file systems.
>>> +This utility does not work on active file systems.
>>>  To change the root file system, the system must be rebooted
>>>  after the file system is tuned.
>>
>> Hmm, if it doesn't work on active file system, there is no way to
>> change the root file system :)

It's certainly supposed to work for the root file system.  In 4.4BSD,
this working was fragile, as partly explained above.  -- Hmm, this
commit was more broken that I first noticed (see other mail).  It makes
the second sentence in the above paragraph more inconsistent with the
first sentence than before.  The first sentence says that tunefs DOES
NOT work.  The second sentence still says that tuning using tunefs (if
not tunefs itself) does work after the system is rebooted. --  The
fragile working was as follows:

(1) 4.4BSD wasn't missing block devices

(2) the only restrictions on writing to the character device corresponding
     to a mounted block device were:
     (a) at securelevel >= 1
     (b) fsck had some internal restrictions, or at least partly understood
 	the problem and tried to do the right thing for a root file system
 	mounted read-only -- this involves writing to the cdev and then
 	updating the bdev using mount(...MNT_UPDATE...).  This was supposed
 	to be only supported for the root file system, but determination of
 	the of the mounted root bdev corresponding to the cdev being fscked
 	was fragile.

(3) tunefs had no understanding of this problem.  It happlily wrote to the
     cdev (at least if you started old it operate on a cdev).  Thus, even
     if the root file system, or any file system, was mounted r/w and active,
     you could change its superblock using tunefs.  The mounted file system
     wouldn't see the changes, but might after reboot.  If the mount was r/o,
     then the changes made by tunefs were preserved on reboot and did work
     after reboot.  If the mount was r/w, then I think unmount normally
     clobbered any changes made by tunefs, but you could probably reboot
     with no sync and then have the changes work after reboot.  The second
     sentence in the above part of the man page is about doing this in the
     nice case when the root file system is mounted r/o.  It fails to
     mention the requirement that the file system is mounted r/o.  This
     seems to have been out of date even in 4.4BSD -- rebooting shouldn't
     have been necessary, since you could just force the necessary
     mount(...MNT_UPDATE...) using mount -u.  tunefs plus mount -u had a
     good chance of working safely (but with minor races) even for r/w
     mounts.

FreeBSD fixed tunefs in 1999 to do the necessary mount(...MOUNT_UPDATE...)
automatically in the r/o mount case so that the complications in (3)
and the second sentence in the above part of the man page mostly no
longer matter.  They still applied to r/w mounts.

(1a) FreeBSD broke (axed) support for block devices later in 1999 or 2000.

(2a) When block devices were broken, the hack in (2) was replaced by an
      diffently fragile hack and to support fsck.  Now there is only a
      cdev, it is easy to prevent opens for write on a mounted cdev,
      but this restriction cannot be completly enforced without breaking
      fsck on the root file system (mounted r/o), and also tunefs on
      r/o mounts.  Opens for writing were disallowed on cdevs for file
      systems mounted r/w, but allowed on cdevs for file systems mounted
      r/o.  This almost completed the bitrot in the second sentence in
      the above part of in the man page -- now the r/w mount case is
      unreachable and the r/o case doesn't need a reboot; there is no
      longer any fragility associating the device being written to by
      tunefs with a mounted device, but there is associated fragility
      invlolving writing via an cdev alias or container device -- the
      alias just needs to be another cdev instead of a bdev.

(3a) Hack (2a) kept tunefs and of course fsck working on cdevs for file
      systems mounted r/o.  Now they fail better on cdevs for file systems
      mounted r/w.

> Booting with alternative root (possibly from alternative media)?

As you know, there is further breakage in this area:

(2b) AFIAK, the hack is now only applied to the root file system and then
      only to its initial r/o mount.  Thus even fsck on a cdev for the root
      file system mounted r/o is now broken except for the initial mount.
      E.g., "kill -TERM 1" followed by umount -A (and "mount -u -o ro /")
      is no longer sufficient for fscking the root file system after entering
      multi-user mode.

(3b) I guess tunefs on cdevs mounted r/o is now broken by (2b), except for
      the initial r/o mount of the root file system.  Changes near (2b) also
      prevent writing via aliases and containers.  This more than completes
      the bitrot in the second sentence in the above part of the man page --
      the r/w case is now unreachable, and the r/o case is mostly unreachable
      too :-(.

Bruce