Re: Autorebuild, new dynamic udev rules for hot-plugs

[Dan Williams <dan.j.williams@intel.com>]

On 11/22/2010 5:17 PM, Neil Brown wrote:
> On Mon, 22 Nov 2010 16:11:41 -0800
> Dan Williams<dan.j.williams@intel.com>  wrote:
>
>> On 11/22/2010 3:50 PM, Hawrylewicz Czarnowski, Przemyslaw wrote:
>>>> Four comments.
>>>>
>>>> 1/ I wouldn't write a file in /lib/udev/rules.d/
>>>>     I think it should be written to "/dev/.udev/rules.d/"
>>>>     which is referred to as the "temporary rules directory"
>>>>     in the udev documentation.
>>> I am not sure if it is what we are looking for. Temporary means they disappear after reboot. It is OK as cold-plug does not need support for bare disks (or maybe I am wrong?). But in such case, one who wants to use autorebuild should invoke mdadm --activate-domains for example in /etc/init.d/local.boot or somewhere else. Second idea here is to use ActivateDomain() when one starts monitor with autorebuild enabled. Which one? I would prefer to leave it as it was written initially (considering comment #4). Then, if one removes policies from config, invoking --activate-domains should reset/remove rules (but see #3)
>>
>> The intent was always to have this be something reinitialized at boot.
>> Putting these in the temporary rule directory also precludes them from
>> being added to the initramfs where they are not needed / potentially
>> confusing.
>>
>> The other intent was to only match the pci paths for the controllers we
>> cared about.  That does not appear to be a part of this patch.
>
> Can you define "we cared about".  Don't we care about everything listed in
> mdadm.conf??

A hot plug event outside of ahci (in raid mode), or the upcoming isci 
driver needs to be ignored and an error thrown on activate if we can 
unambiguously determine that the domain defines firmware unreachable 
devices.

The IMSM_NO_PLATFORM debug environment variable can override this 
behavior, or in the ahci case you can run in raid disabled mode.  I need 
to check if the same raid disabled case holds for isci.

>
> We could avoid both these issues by just writing the new rules file to stdout.
> When when the init script gets it wrong, it isn't our fault :-)
>
> But I don't really like that.  At least there should be a simple and uniform
> way to propagate any mdadm.conf changes into udev.
>
> Maybe the name of the rules file should be given in mdadm.conf, and e.g.
>    mdadm --check-config
> would report any syntax errors, report any inconsistencies with current
> arrays, and update the udev file if necessary..
>
> Maybe leave that for 3.2.1, and just support '--activate-domains=filename'
> for now.
>
> ???

A more generic mdadm.conf checker sounds like a good idea in general.

--
Dan