Date: Fri, 07 Nov 2003 15:48:42 -0800 From: Kirk McKusick <mckusick@beastie.mckusick.com> To: Bruce Evans <bde@zeta.org.au> Cc: arch@freebsd.org Subject: Re: newfs and mount vs. half-baked disks Message-ID: <200311072348.hA7NmgaG000289@beastie.mckusick.com> In-Reply-To: Your message of "Fri, 07 Nov 2003 22:01:21 %2B1100." <20031107211239.O3343@gamplex.bde.org>
next in thread | previous in thread | raw e-mail | index | archive | help
> 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 > X-ASK-Info: Whitelist match > > 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. You cannot depend on the disk label as the disklabel is going away or at least being wholly overhauled with GEOM. In particular, the existing disk label only has a 2^32 block count which is insufficient for filesystems larger than 2Tb. > 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. > > Bruce I concur that knocking out the magic number will have the benefit of making all the existing utilities and kernels refuse to inspect / mount the filesystem. Kirk McKusick
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200311072348.hA7NmgaG000289>