Date: Fri, 7 Nov 2003 22:01:21 +1100 (EST) From: Bruce Evans <bde@zeta.org.au> To: Wes Peters <wes@softweyr.com> Cc: arch@FreeBSD.org Subject: Re: newfs and mount vs. half-baked disks Message-ID: <20031107211239.O3343@gamplex.bde.org> In-Reply-To: <200311061652.48948.wes@softweyr.com> References: <200311041737.20467.wes@softweyr.com> <20031105213950.Y1738@gamplex.bde.org> <200311061652.48948.wes@softweyr.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, 6 Nov 2003, Wes Peters wrote: > On Wednesday 05 November 2003 03:18, Bruce Evans wrote: > > On Tue, 4 Nov 2003, Wes Peters wrote: > > > > > > I emailed Kirk about this state of affairs and he confirmed that > > > newfs was developed with operator intervention in mind. He > > > suggested employing one of the unused flags in the filesystem > > > header as a 'consistent' flag, setting it to 'not consistent' at > > > the beginning of newfs, and then updating to 'is consistent' at the > > > end. The performance hit in updating all superblock copies at the > > > end is small but noticable (< 1s on a rather slow 6GB filesystem). > > > > There is no need to use a new flag. Just set the magic number to a > > value different from both FS_UFS1_MAGIC and FS_UFS2_MAGIC, e.g., to > > 0, until newfs is nearly finished. > > I specifically don't want to do that because I want the state > "interrupted newfs operation" to be discernable from the state > "something stomped on your superblock." This I believe better shows > that the superblock is valid but the filesystem is not (yet). That's not a very useful distinction, especially for your application where the disk contents is disposable and you re-newfs it a lot. After a crash the complete state (as given by the disk contents) may be almost anywhwere between its initial and final values, depending on buffering etc., so it would be very difficult just to determine what it is if you needed it. Some cases can be discerned anyway, depending on how much erasing of metadata newfs does when it starts. E.g., if there was an ffs file system on the disk, then this will be recorded in the disk label unless that feature has been axed). newfs doesn't rewrite the label until just before it finishes, so the old label can be looked at to determine what was there. Writing the label last may be a bug though. Perhaps newfs should erase all the primary metadata for the old filesystem when it starts so as to minimise the window where there may be conflicting metadata. Clearing the magic number works better because it requires no kernel changes and no changes to applications other than ufs. In particular, half-baked file systems formatted with the changed newfs work right under all versions of FreeBSD (i.e., they don't work and don't cause panics), and utilities like dumpfs and fsdb don't need to be changed to display and/or edit the newly used field. > The name fs_state suggests someone was thinking of recording some sort > of state in here that was never implemented. I've simply used it to > record states 'newfs operation completed' and 'newfs operation not > completed.' Its comment also suggests that it was for validating fs_clean. This goes back to at least FreeBSD-1 where both fs_state and fs_clean are unused. fs_clean wasn't used in 4.4BSD-Lite1 either. Use of it was added in FreeBSD and/or NetBSD and picked up by Lite2. I am nervous about using yet another variable for things related to state. There is a large enough mess for fs_clean already. We now also have FS_UNCLEAN in fs_flags (which were also unused until relatively recently). As I understand it (the details were simpler when I understood them all), FS_UNCLEAN was originally fs_clean done right except it probably belongs in fs_state. It was just fs_clean inverted and put in a bitmap. Now FS_UNCLEAN is tangled up with FS_NEEDSFSCK and is not simply fs_clean inverted. Bruce
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20031107211239.O3343>