On Saturday 15 November 2008, martin f krafft <madduck@debian.org> wrote about 'mdadm device assembly (was: udev causing data loss?)': >also sprach ghe <ghe@slsware.com> [2008.11.15.1842 +0100]: >> mdadm, I noticed yesterday, seems to be able to figure things out >> and build its RAID arrays from the correct disks, even when the >> /dev names are have changed since the arrays were defined. Bears >> looking into -- I suspect UUIDs, but one mustn't jump to >> conclusions :-) I know that's how it finds my devices: # definitions of existing MD arrays ARRAY /dev/md0 level=raid1 num-devices=2 UUID=077c05cf:a4327216:e66ff801:2a27e10e ARRAY /dev/md1 level=raid0 num-devices=2 UUID=545ff3bf:a0b1e945:cdc2686e:85a2cec5 >mdadm does work which udev could/should be doing. I am not too much >of a udev friend, and we must not depend on it, but prepare for >mdadm and udev to cooperate much closer post-lenny. Are mdadm's UUIDs not the same as udev's? >http://www.spinics.net/lists/raid/threads.html#20834 Didn't read it all right now. Perhaps later. >The way mdadm finds and assembles its components is by scanning >disks or partitions (DEVICE setting, or -c option) for superblocks. >The whole process is somewhat twisted and I hope we can rework it >one day. That seems sane, not twisting at all, to me. Last I checked this is also the way LVM works. Will lvm2 be getting a similar "fix"? -- Boyd Stephen Smith Jr. ,= ,-_-. =. bss03@volumehost.net ((_/)o o(\_)) ICQ: 514984 YM/AIM: DaTwinkDaddy `-'(. .)`-' http://iguanasuicide.org/ \_/
Attachment:
signature.asc
Description: This is a digitally signed message part.