On Wed, 2007-10-24 at 16:22 -0400, Bill Davidsen wrote:
> Doug Ledford wrote:
> > On Mon, 2007-10-22 at 16:39 -0400, John Stoffel wrote:
> >
> >
> >> I don't agree completely. I think the superblock location is a key
> >> issue, because if you have a superblock location which moves depending
> >> the filesystem or LVM you use to look at the partition (or full disk)
> >> then you need to be even more careful about how to poke at things.
> >>
> >
> > This is the heart of the matter. When you consider that each file
> > system and each volume management stack has a superblock, and they some
> > store their superblocks at the end of devices and some at the beginning,
> > and they can be stacked, then it becomes next to impossible to make sure
> > a stacked setup is never recognized incorrectly under any circumstance.
> > It might be possible if you use static device names, but our users
> > *long* ago complained very loudly when adding a new disk or removing a
> > bad disk caused their setup to fail to boot. So, along came mount by
> > label and auto scans for superblocks. Once you do that, you *really*
> > need all the superblocks at the same end of a device so when you stack
> > things, it always works properly.
> Let me be devil's advocate, I noted in another post that location might
> be raid level dependent. For raid-1 putting the superblock at the end
> allows the BIOS to treat a single partition as a bootable unit.
This is true for both the 1.0 and 1.2 superblock formats. The BIOS
couldn't care less if there is an offset to the filesystem because it
doesn't try to read from the filesystem. It just jumps to the first 512
byte sector and that's it. Grub/Lilo are the ones that have to know
about the offset, and they would be made aware of the offset at install
time.
So, we are back to the exact same thing I was talking about. With the
superblock at the beginning of the device, you don't hinder bootability
with or without the raid working, the raid would be bootable regardless
as long as you made it bootable, it only hinders accessing the
filesystem via a running linux installation without bringing up the
raid.
> For all
> other arrangements the end location puts the superblock where it is
> slightly more likely to be overwritten, and where it must be moved if
> the partition grows or whatever.
>
> There really may be no "right" answer.
--
Doug Ledford <dledford@xxxxxxxxxx>
GPG KeyID: CFBFF194
http://people.redhat.com/dledford
Infiniband specific RPMs available at
http://people.redhat.com/dledford/Infiniband
Attachment:
signature.asc
Description: This is a digitally signed message part
