Re: newfs and mount vs. half-baked disks
From: Kirk McKusick (mckusick_at_beastie.mckusick.com)
Date: 11/10/03
- Previous message: Wes Peters: "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: Sun, 09 Nov 2003 15:51:55 -0800
> Date: Sat, 8 Nov 2003 19:35:16 +1100 (EST)
> From: Bruce Evans <bde@zeta.org.au>
> X-X-Sender: bde@gamplex.bde.org
> To: Kirk McKusick <mckusick@mckusick.com>
> Cc: arch@freebsd.org
> Subject: Re: newfs and mount vs. half-baked disks
> X-ASK-Info: Whitelist match
>
> 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.)
I agree that there needs to be some place that the additional information
be stored to let fsck find the alternate superblocks. However, it seems
unllikely that it will be the disk label as FreeBSD is looking to go to
one of the existing disk label standards which do not have space reserved
for that purpose. So, my guess is that some of the "boot" area will have
to be reserved to that purpose.
> 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
Actually, FFS requires its fragment size be no smaller than the sector size
(since it presumes that it cannot do read/write in smaller than sector
sizes). So, on a 16K filesystem, you get 2K fragments. So your hack only
gets you to 8TB which is not going to last long at current disk growth
rates.
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: Wes Peters: "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
- SUMMARY: Cant Read Disk Label (Thanks Mike!)
... Thanks to Mike David Chanslor for helping me to fix my "Can't Read Disk ...
We now stick to Seagate IDE drives ... Subject: Can't read disk label. ...
I am trying to install Solaris 8 on a Sun Ultra 10 Sparc ... (SunManagers) - Re: Path syntax in VBA
... the path at all -- Windows doesn't "understand" disk labels in paths ... then
use the corresponding drive letter in the save path. ... >Jonathan West - Word MVP
... >> The question is can I use the disk label in the path instead of the drive
... (microsoft.public.word.vba.general) - Re: newfs and mount vs. half-baked disks
... > where the disk contents is disposable and you re-newfs it a lot. ... >
metadata newfs does when it starts. ... > newfs should erase all the primary metadata
for the old filesystem ... You cannot depend on the disk label as the disklabel
is going away ... (freebsd-arch) - Solaris 9 Install on 220R - Bad Magic number on boot cdrom
... I am able to go to /cdrom and see that the Solaris 9 media is readable ... When
I try and do a boot cdrom I get a bad Magic number message ... Bad magic number in disk
label ... (comp.unix.solaris) - Re: Using a hard drive without partitions
... One of the main reasons for using a DD disk is so you don't have to ... Do you
want to mount it for files? ... Your s1 probably starts at the 64th sector. ...
after the disk label area. ... (freebsd-questions)