Neil Brown wrote:
What constitutes 'a piece of data'? A bit? a byte?
I would say that
msdos:fd
is one piece of data. The 'fd' is useless without the 'msdos'.
The 'msdos' is, I guess, not completely useless with the fd.
I would lean towards the composite, but I wouldn't fight a separation.
Well, the two pieces come from different sources.
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*!)
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.
-hpa
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
