Re: newfs and mount vs. half-baked disks
From: Kirk McKusick (mckusick_at_beastie.mckusick.com)
Date: 11/08/03
- Previous message: Bruce Evans: "Re: newfs and mount vs. half-baked disks"
- In reply to: Bruce Evans: "Re: newfs and mount vs. half-baked disks"
- Next in thread: Bruce Evans: "Re: newfs and mount vs. half-baked disks"
- Reply: Bruce Evans: "Re: newfs and mount vs. half-baked disks"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
To: Bruce Evans <bde@zeta.org.au> Date: Fri, 07 Nov 2003 15:48:42 -0800
> 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
_______________________________________________
freebsd-arch@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org"
- Previous message: Bruce Evans: "Re: newfs and mount vs. half-baked disks"
- In reply to: Bruce Evans: "Re: newfs and mount vs. half-baked disks"
- Next in thread: Bruce Evans: "Re: newfs and mount vs. half-baked disks"
- Reply: Bruce Evans: "Re: newfs and mount vs. half-baked disks"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
|
