Re: [klibc] Re: Exporting which partitions to md-configure

[Neil Brown <neilb@suse.de>]

On Monday February 6, hpa@zytor.com wrote:
> Neil Brown wrote:
> > 
> > Just as there is a direct unambiguous causal path from something
> > present at early boot to the root filesystem that is mounted (and the
> > root filesystem specifies all other filesystems through fstab)
> > similarly there should be an unambiguous causal path from something
> > present at early boot to the array which holds the root filesystem -
> > and the root filesystem should describe all other arrays via
> > mdadm.conf
> > 
> > Does that make sense?
> > 
> 
> It makes sense, but I disagree.  I believe you are correct in that the 
> current "preferred minor" bit causes an invalid assumption that, e.g. 
> /dev/md3 is always a certain thing, but since each array has a UUID, and 
> one should be able to mount by either filesystem UUID or array UUID, 
> there should be no need for such a conflict if one allows for dynamic md 
> numbers.
> 
> Requiring that mdadm.conf describes the actual state of all volumes 
> would be an enormous step in the wrong direction.  Right now, the Linux 
> md system can handle some very oddball hardware changes (such as on 
> hera.kernel.org, when the disks not just completely changed names due to 
> a controller change, but changed from hd* to sd*!)

mdadm.conf doesn't need to, and normally shouldn't, list the devices
that compose an array (though it can if you want it to).

A typical mdadm.conf should look something like:

   DEVICES /dev/hd* /dev/sd*
   ARRAY /dev/md0 UUID=some:long:uuid
   ARRAY /dev/md1 UUID=some:other:long:uuid

So I think we are actually in agreement.

> 
> Dynamicity is a good thing, although it needs to be harnessed.
> 
>  > kernel parameter md_root_uuid=xxyy:zzyy:aabb:ccdd...
>  >    This could be interpreted by an initramfs script to run mdadm
>  >    to find and assemble the array with that uuid.  The uuid of
>  >    each array is reasonably unique.
> 
> This, in fact is *EXACTLY* what we're talking about; it does require 
> autoassemble.  Why do we care about the partition types at all?  The 
> reason is that since the md superblock is at the end, it doesn't get 
> automatically wiped if the partition is used as a raw filesystem, and so 
> it's important that there is a qualifier for it.

Maybe I should be explicit about what I am against.
I am against the practice of choosing devices to assemble into arrays
based simply on a partition type - and assembling them into whatever
arrays they appear to comprise.

A device should not be able to say "pick me, pick me!".  Something
*outside* the array should say "pick all devices matching X", where X
is some arbitrary predicate, that could involve partition type
information if you like, but importantly should be precise enough not
to choose wrongly in any but very exceptional circumstances.

I am *not* against 'autoassemble' in the sense that some process hunts
through available devices trying to find the components for a give md
array: It was primarily to achieve this that I wrote mdadm.  I just
want the 'autoassemble' to be driven by some external description of
the array(s) - e.g. uuid.

I don't accept your argument that partition types are of interest
because array components could still have their superblock after being
retargeted.  This is because
  - running "mdadm --zero-superblock" is as easy as changing the
    partition type, and equally, both are easy to forget to do.
  - If you have retargeted devices in an array, you presumably don't
    put the UUID of that array anywhere that would encourage mdadm to
    assemble it.  So the fact that the UUID won't be recognised is
    just as good at stopping the array from being assembled as that
    fact that the partition type has been changed.

This doesn't mean I am violently against partition types (and for
legacy support, we need to use them).  I just don't see a lot of value
in using them.

NeilBrown
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/