On 02/15/2010 04:27 PM, Neil Brown wrote:That is either a problem or a solution, depending which bad behavior you are trying hardest to avoid.
When mdadm defaults to 1.0 for a RAID1 it prints a warning to the effect that
the array might not be suitable to store '/boot', and requests confirmation.
So I assume that the people who are having this problem either do not read,
or are using some partitioning tool that runs mdadm under the hood using
"--run" to avoid the need for confirmation. It would be nice to confirm if
that was the case, and find out what tool is being used.
My guess is that they are using the latter. However, some of it is
probably also a matter of not planning ahead, or not understanding the
error message. I'll forward one email privately (don't want to forward
a private email to a list.)
If an array is not being used for /boot (or /) then I still think that 1.1 is
the better choice as it removes the possibility for confusion over partition
tables.
I guess I could try defaulting to 1.2 in a partition, and 1.1 on a
whole-device. That might be a suitable compromise.
In some ways, 1.1 is even more toxic on a whole-device, since that means
that it is physically impossible to boot off of it -- the hardware will
only ever read the first sector (MBR).
And certainly there are other reasons to do that...How do people cope with XFS??
There are three options:
a) either don't boot from it (separate /boot);
b) use a bootloader which installs in the MBR and
hopefully-unpartitioned disk areas (e.g. Grub);
c) use a nonstandard custom MBR.
Neither (b) or (c), of course, allow for chainloading from another OS
install and thus are bad for interoperability.