On Mon, 22 Nov 2010 21:04:07 -0800 Dan Williams <dan.j.williams@xxxxxxxxx> 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@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. 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 -- 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
