Re: newfs and mount vs. half-baked disks

From: Bruce Evans (bde_at_zeta.org.au)
Date: 11/08/03

  • Next message: Wes Peters: "Re: newfs and mount vs. half-baked disks" 
    Date: Sat, 8 Nov 2003 19:35:16 +1100 (EST)
To: Kirk McKusick <mckusick@beastie.mckusick.com>

    On Fri, 7 Nov 2003, Kirk McKusick wrote:

    > > From: Bruce Evans <bde@zeta.org.au>
    > > ...
    > > 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.

    I don't use GEOM, so the label won't be going away for me. Anyway, there
    is no dependency (the label is just one of the things that one might
    examine to recover a crashed disk), and any overaul by GEOM would have
    to duplicate the functionality of storing metadata about the superblocks
    somewhere outside the superblocks. (I actually store metadata about file
    systems in (backups of) disk files in /var/backups. Normal backups
    provide inadequate backups of metadata.)

    The block count is in units of sector size, so disks much larger than
    2TB can be supported by disklabel using (fake if necessary) sector sizes
    larger than 512. File systems need to use similarly large block (fragment
    for ffs) sizes, and some patches are needed for reading superblocks if
    the sector size is larger than 8K. Since ffs uses a block size of 16K
    by default, a sector size of 16K are not unreasonable and this is sufficent
    for disks smaller then 64TB.

    Bruce
    _______________________________________________
    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"

  • Next message: Wes Peters: "Re: newfs and mount vs. half-baked disks"

    Relevant Pages

    • Re: newfs and mount vs. half-baked disks
      ... > where the disk contents is disposable and you re-newfs it a lot. ... but after the newfs we take different actions depending on whether we ... > metadata newfs does when it starts. ... then this will be recorded in the disk label unless ...
      (freebsd-arch)
    • Re: Creating slices - Im lost.
      ... a useful swap disk. ... > * Sector Count Sector ... >> current label and search for backup label)? ...
      (comp.sys.sun.admin)
    • gmirror metadata: end of slice or end of disk?
      ... I'm trying to understand exactly where on disk gmirror is going to write ... its metadata, and was hoping I could elicit comments on whether I have ... Assume my disk, da1, has a single slice, and I partition it as follows ... belief is that gmirror will write its metadata into sector 499 (the ...
      (freebsd-questions)
    • Re: Creating slices - Im lost.
      ... Sector Count Sector ... Could you try a devfsadm -Cvc disk please. ... > with selections of verify and backup (verify current label and search ... despite format reporting silly values. ...
      (comp.sys.sun.admin)
    • glabel metadata protection (WAS: ZFS: drive replacement performance)
      ... glabel metadata is protected in any way? ... disk and then create a pool using /dev/label/disklabel, ... Disks labeled with glabel lose their last sector to the label. ...
      (freebsd-stable)