Hi,
On 04/14/2010 01:04 AM, David Lehman wrote:
<snip>
This makes me nervous. What else are we changing here besides firmware
raid? Don't say nothing -- I won't believe you.
We are telling mdadm that it is ok to auto assembly imsm (Intel firmware RAID)
*and* normal mdraid sets with a metadata version of 1.x, which are sets
either manually created by people, or created by the F-13 (or later) anaconda.
The idea here is that 1.x metadata contains a homehost identifier, so if some
random disk with mdraid 1.x metadata is plugged in, the homehost won't match
and thus it won't be auto assembled, where as sets created on the host which
The imsm part is fine with me, but not the 1.x. You could argue that it
depends on the whole-system philosophy on automatic assembly/activation
of high-level devices like lvm and md. I'm fairly certain that lvm does
not do auto-activation.
Goin a bit off topic here, but lvm actually does assemble anything under the
sun which remotely looks like lvm on boot up.
More to the point, this activates only md
devices that can reasonably be believed to be local. What about the
other ones (older metadata, non-matching homehost)? Am I crazy for
caring that we seem to be aiming for as little consistency as is humanly
possible?
I don't feel this is my call to make. If Doug wants this to be the defaults for
mdraid, so be it. I'm just following his wishes here, this policy needs to be in
anaconda as anaconda (over)writes the config file, but it really is mdadm policy
not anaconda policy.
Regards,
Hans
_______________________________________________
Anaconda-devel-list mailing list
Anaconda-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/anaconda-devel-list
