Bug 453686

+++ This bug was initially created as a clone of Bug #447818 +++


-- Additional comment from george.joseph on 2008-06-29 00:39 EST --
Sorry but mdadm-2.6.7-1.fc9 does not fix the problem.

1.  The udev rule will only fire if the array is composed of partitions with a
type of 'fd'.  I.E.  The block devices sdb and sdc each have a partition table
with a partition set to 'fd', then the array is composed of sdb1 and sdc1.  The
udev rule does NOT fire if the array is composed of the sdb and sdc devices
directly because the rule looks for a fs type of "linux_raid*".

-- Additional comment from dledford on 2008-07-01 17:09 EST --
(In reply to comment #14)
> Sorry but mdadm-2.6.7-1.fc9 does not fix the problem.
> 
> 1.  The udev rule will only fire if the array is composed of partitions with a
> type of 'fd'.  I.E.  The block devices sdb and sdc each have a partition table
> with a partition set to 'fd', then the array is composed of sdb1 and sdc1.  The
> udev rule does NOT fire if the array is composed of the sdb and sdc devices
> directly because the rule looks for a fs type of "linux_raid*".

I don't have a spare disk to remove the partition table on and test this, but I
did test this by trying to see how udev responded to loopback devices that had
no disk partition on them.  In that case, udev was smart enough to know it was a
linux raid device *without* a partition table, and without a partition table
type of 0xfd.  Instead, it was reading from the disk and looking for a raid
superblock (I specifically test version 0.90 and 1.1 superblocks and it found
both types, and it even changed ID_FS_VERSION to match the raid superblock type).

You can duplicate my tests yourself by running:

/lib/udev/vol_id /dev/<devicename>

and checking the output.  If you could please run the above command on a whole
disk device under your setup and verify whether or not it correctly identifies
the whole disk device, I would appreciate it.


-- Additional comment from george.joseph on 2008-07-01 18:15 EST --
Still 2 strikes but I've got some additional info...

The udev rule does not fire for raw block devices I think because nothing ever
triggers vol_id to run.  When I do a udevadm --test /block/sdb/sdb1, I can see
in the output that vol_id is run and ID_FS_TYPE is set correctly to
linux_raid_member.  I can also see the mdadm rule run.  When I do the same test
on /block/sdb, vol_id is never run so ID_FS_TYPE is not set and mdadm is not
run.  It looks like 60-persistent-storage.rules only runs vol_id for partitions.


-- Additional comment from dledford on 2008-07-01 18:24 EST --
Thanks for checking on that.  So, for the first issue, I don't think that's an
mdadm or md raid bug if udev is configured not to run vol_id on whole block
devices.  I know the upstream maintainer of mdadm/md kernel driver actually
prefers running his raid arrays on the bare block devices, so I think that's
something that needs to be supported.  However, I could also imagine that udev
might have problems with whole disk devices and hitting false positive matches,
which might be why they only do partitions.  I think it's something that needs a
new bug under the udev component, so I'll go ahead and clone this bug for that
purpose.