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

[Neil Brown <neilb@suse.de>]

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.


NeilBrown




> 
> 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