Re: [PATCH v2] block: deprecate autoloading based on dev_t

[Dan Moulding <dmoulding@me.com>]

I believe this change may break some mdraid setups. It looks to me
like mdadm still depends on this legacy autoload behavior. There are
some situations where mdadm does mknod to create a temporary device
node and then attempts to open that temporary node. On my system,
after disabling legacy autoloading, mdadm fails (ENODEV) when it
attempts the open of the temporary node (block 9:127).

It seems this is an issue when mdadm attempts to assemble an array
that it sees as "foreign". And it makes the determination of whether
an array is foreign or not based on whether the hostname recorded in
the array superblock(s) matches the current system's hostname. It's my
observation that some init systems do not set the system hostname
early enough, so arrays that should look local will be treated as
foreign arrays by mdadm, which makes it go down this path where it
will depend on the legacy autoloading behavior.

As an aside, this happens even though udev is in use. mdadm ships with
udev rules that cause mdadm to be invoked to assemble arrays when
uevents fire that announce the appearance of "file systems" of type
linux_raid_member. So while udev is supposed to supplant this legacy
autoloading behavior, it appears there are at least some current
real-world cases where udev itself ultimately ends up itself depending
(in an indirect way) on this legacy behavior :)

Cheers,

-- Dan