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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 11/22/2010 5:17 PM, Neil Brown wrote:
On Mon, 22 Nov 2010 16:11:41 -0800
Dan Williams<dan.j.williams@xxxxxxxxx>  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
--
To unsubscribe from this list: send the line "unsubscribe linux-raid" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Index of Archives]     [Linux RAID Wiki]     [ATA RAID]     [Linux SCSI Target Infrastructure]     [Linux Block]     [Linux IDE]     [Linux SCSI]     [Linux Hams]     [Device Mapper]     [Device Mapper Cryptographics]     [Kernel]     [Linux Admin]     [Linux Net]     [GFS]     [RPM]     [git]     [Yosemite Forum]


  Powered by Linux