From owner-svn-src-head@FreeBSD.ORG Wed Oct 21 13:50:19 2009 Return-Path: Delivered-To: svn-src-head@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 35E171065670; Wed, 21 Oct 2009 13:50:19 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail04.syd.optusnet.com.au (mail04.syd.optusnet.com.au [211.29.132.185]) by mx1.freebsd.org (Postfix) with ESMTP id BD1868FC12; Wed, 21 Oct 2009 13:50:18 +0000 (UTC) Received: from c122-106-156-249.carlnfd1.nsw.optusnet.com.au (c122-106-156-249.carlnfd1.nsw.optusnet.com.au [122.106.156.249]) by mail04.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id n9LDoEtD026799 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 22 Oct 2009 00:50:16 +1100 Date: Thu, 22 Oct 2009 00:50:14 +1100 (EST) From: Bruce Evans X-X-Sender: bde@delplex.bde.org To: Andriy Gapon In-Reply-To: <4ADEF6C8.3060808@freebsd.org> Message-ID: <20091021233345.N12823@delplex.bde.org> References: <200910211015.n9LAFQwY094532@svn.freebsd.org> <9bbcef730910210428i4b39b358sbcfb76d882a4c24a@mail.gmail.com> <4ADEF6C8.3060808@freebsd.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: svn-src-head@FreeBSD.org, Remko Lodder , src-committers@FreeBSD.org, Ivan Voras , svn-src-all@FreeBSD.org Subject: Re: svn commit: r198316 - head/sbin/tunefs X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Oct 2009 13:50:19 -0000 On Wed, 21 Oct 2009, Andriy Gapon wrote: > on 21/10/2009 14:28 Ivan Voras said the following: >> 2009/10/21 Remko Lodder : >>> 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