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
