Thread (27 messages) 27 messages, 5 authors, 2010-12-23

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

From: Dan Williams <hidden>
Date: 2010-11-23 05:04:07

On 11/22/2010 5:17 PM, Neil Brown wrote:
On Mon, 22 Nov 2010 16:11:41 -0800
Dan Williams[off-list ref]  wrote:
quoted
On 11/22/2010 3:50 PM, Hawrylewicz Czarnowski, Przemyslaw wrote:
quoted
quoted
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
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help