On 01/03/2012 05:24 AM, Jes Sorensen wrote: > On 12/23/11 00:48, NeilBrown wrote: >> On Fri, 21 Oct 2011 15:33:19 +0200 Jes.Sorensen@redhat.com wrote: >> >>> From: Jes Sorensen >>> >>> Signed-off-by: Jes Sorensen >>> --- >>> Incremental.c | 1 - >>> 1 files changed, 0 insertions(+), 1 deletions(-) >>> >>> diff --git a/Incremental.c b/Incremental.c >>> index 1a9a97b..cff7663 100644 >>> --- a/Incremental.c >>> +++ b/Incremental.c >>> @@ -446,7 +446,6 @@ int Incremental(char *devname, int verbose, int runstop, >>> if (info.array.level == LEVEL_CONTAINER) { >>> int devnum = devnum; /* defined and used iff ->external */ >>> /* Try to assemble within the container */ >>> - sysfs_uevent(&info, "change"); >>> if (verbose >= 0) >>> fprintf(stderr, Name >>> ": container %s now has %d devices\n", >> >> Hi Jes, >> I've had to revert this patch as it causes a regression. >> >> Without the 'change' event the container device doesn't get created in /dev. >> >> I'm not sure udev should be running "--incremental" on containers anyway, but >> if it does it shouldn't cause problems should it? If it does we should fix >> those problems. > > Hi Neil, > > I am wary of this being reverted as it fixed a genuine race condition. > On Fedora we don't have the problem with the container device not being > created, could it be that your udev scripts are not doing the right > thing in this case? I think it's probably worthwhile for us to do a udev rules file comparison. So, I'm attaching the patch we apply to the udev rules file in your distribution before installing it, as also the rules file that handles incremental assembly on Fedora/RHEL. Look them over and see if you want to include any of the things we have there in your version. As to the question of udev running incremental on containers, I think it's fair to say that either udev or mdadm should be doing so, and not both. Whether it should be one or the other is up for debate I think. Doing it in mdadm where this patch pulls it out means that it only happens on add of a new device using incremental assembly. The udev version does it on a change event on the container. The question I have is, if you had mdmon migrate a spare into a container, would it trigger this code in mdadm versus would it trigger the code in the udev rules file? Is there any situation where a change triggered via something other than incremental assembly would result in us needing to run incremental on the container? If the answer is yes, then I would recommend doing things in the udev file versus in the incremental function of mdadm. -- Doug Ledford GPG KeyID: 0E572FDD http://people.redhat.com/dledford