Re: newfs and mount vs. half-baked disks

From: Wes Peters (wes_at_softweyr.com)
Date: 11/07/03

  • Next message: Bruce Evans: "Re: >0x7fffffff blocksize filesystem reporting"
    To: Bruce Evans <bde@zeta.org.au>
    Date: Thu, 6 Nov 2003 16:52:48 -0800
    
    

    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).

    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.'

    -- 
             "Where am I, and what am I doing in this handbasket?"
    Wes Peters                                              wes@softweyr.com
    _______________________________________________
    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: Bruce Evans: "Re: >0x7fffffff blocksize filesystem reporting"

    Relevant Pages

    • Re: newfs and mount vs. half-baked disks
      ... > clean we just newfs and mount the clean new filesystem. ... > performance hit in updating all superblock copies at the end is small ... since the superblock for the previous file system may ... Newfs should also set the unclean flags and any related flags until it ...
      (freebsd-arch)
    • Re: newfs and mount vs. half-baked disks
      ... >> newfs was developed with operator intervention in mind. ... >> performance hit in updating all superblock copies at the end is small ... >affecting the filesystem itself? ... My suggestion would be to write a non-standard magic number to ...
      (freebsd-arch)
    • Limiting the number of Superblock duplicates on newfs of huge filesystem
      ... I don't have to newfs filesystems very often so I don't run into this ... I have just built a 500+ GByte RAID-5 user data filesystem. ... I am quite happy to have superblock ... superblock duplicates that get created on a ufs filesystem. ...
      (SunManagers)
    • Re: newfs and mount vs. half-baked disks
      ... > newfs was developed with operator intervention in mind. ... and then updating to 'is consistent' at the end. ... Would writing a block of zeros to the first superblock, ...
      (freebsd-arch)
    • SUMMARY: Bad Superblock
      ... I have a E420 server with Solaris 8 and I get the following message after ... Disk 2 cannot read; block 16, ... # wrong use alternate superblock to supply information. ... running a newfs on the disk and also ran a newfs -Nv c1t0d0s2 for Superblock ...
      (SunManagers)

  • Quantcast