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

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

On 11/22/2010 9:27 PM, Neil Brown wrote:
> On Mon, 22 Nov 2010 21:04:07 -0800
> Dan Williams<dan.j.williams@intel.com>  wrote:
>
>> 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.
>
>
> I can agree that a hot plug event for a non-firmware-reachable device should
> not cause that device to be added to an imsm array.  But the domain setting
> should stop that happening already.
>
> I don't agree (as I *think* you are saying) that hot plug events on such
> devices should be completely ignored by mdadm.  But as I am very surprised
> that you would say that, I suspect I'm misunderstanding.

Well, this comes back to the idea that the user need not be burdened 
with figuring out the pci-device or sas-domain-topology paths of a raid 
controller, especially if that controller changes paths from boot-to-boot.

I see your point that if we define a maximal domain the 
controller/firmware constraints can be applied late to handle the 
clarification.  But if everything is interrogated in this fashion then 
what is the point of dynamically limiting the hot plug path set?  Do we 
need to require explicit definition of a default catch-all domain for 
out-of-firmware-bounds devices?  Now I think I'm the one that is 
misunderstanding :-)

--
Dan