Date: Wed, 5 Nov 2003 19:15:16 +1100 From: Peter Jeremy <PeterJeremy@optushome.com.au> To: Wes Peters <wes@softweyr.com> Cc: arch@freebsd.org Subject: Re: newfs and mount vs. half-baked disks Message-ID: <20031105081516.GA38016@cirb503493.alcatel.com.au> In-Reply-To: <20031105015709.GC28915@dan.emsphone.com> References: <200311041737.20467.wes@softweyr.com> <20031105015709.GC28915@dan.emsphone.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, Nov 04, 2003 at 07:57:10PM -0600, Dan Nelson wrote: >In the last episode (Nov 04), Wes Peters said: >> 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). > >Would writing a block of zeros to the first (or first n) superblock, >newfs'ing, then rewriting the correct data do the same thing without >affecting the filesystem itself? I'm thinking about 4.x and cross-OS >portability here. My suggestion would be to write a non-standard magic number to fs_magic in the primary and first backup superblock (block 32) - I believe these are the only ones fsck will automatically search. The "invalid" magic number means that neither mount nor fsck will recognize the partition. Those two blocks can be re-written at the end - the additional time should be unnoticable. The remaining superblocks would appear valid but if someone is silly enough to manually specify a alternate superblock in an incompletely newfs'd filesystem, they get a neat hole in their foot. (A known non-standard magic number would also allow fsck to warn that the filesystem was incompletely newfs'd). I'm surprised that this bug hasn't been noticed previously. Peter
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20031105081516.GA38016>