Date: Thu, 22 Oct 2009 00:50:14 +1100 (EST) From: Bruce Evans <brde@optusnet.com.au> To: Andriy Gapon <avg@FreeBSD.org> Cc: svn-src-head@FreeBSD.org, Remko Lodder <remko@FreeBSD.org>, src-committers@FreeBSD.org, Ivan Voras <ivoras@FreeBSD.org>, svn-src-all@FreeBSD.org Subject: Re: svn commit: r198316 - head/sbin/tunefs Message-ID: <20091021233345.N12823@delplex.bde.org> In-Reply-To: <4ADEF6C8.3060808@freebsd.org> References: <200910211015.n9LAFQwY094532@svn.freebsd.org> <9bbcef730910210428i4b39b358sbcfb76d882a4c24a@mail.gmail.com> <4ADEF6C8.3060808@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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@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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20091021233345.N12823>