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.

> Michael> Another example is ext[234]fs - it does not touch first 512
> Michael> bytes of the device, so if there was an msdos filesystem
> Michael> there before, it will be recognized as such by many tools,
> Michael> and an attempt to mount it automatically will lead to at
> Michael> least scary output and nothing mounted, or in fsck doing
> Michael> fatal things to it in worst scenario.  Sure thing the first
> Michael> 512 bytes should be just cleared.. but that's another topic.
> 
> I would argue that ext[234] should be clearing those 512 bytes.  Why
> aren't they cleared  

Actually, I didn't think msdos used the first 512 bytes for the same
reason ext3 doesn't: space for a boot sector.

-- 
Doug Ledford <[EMAIL PROTECTED]>
              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

Reply via email to