On 04/08/2010 08:33 PM, Neil Brown wrote: > On Fri, 9 Apr 2010 09:31:53 +1000 > Neil Brown wrote: > >> On Tue, 06 Apr 2010 22:02:58 -0400 >> Doug Ledford wrote: >> >>> Let me know if you want me to redo/resend any of it. >>> >> >> not necessary, but some remove would be appreciated. >> > I suspect you cope graciously with most of my typos, but this one is > ridiculous! > > s/remove/review/ > > :-( > > NeilBrown > > P.S. When could the word "remove" be used in that context? The only excuse > I can think of is that a "remove" is a palette cleanser at a banquet. > So "some remove" would be "some crystallized fruit or ginger bread" - always > appreciated :-) I've already sent two minor patches, the touchup patch from my original submission (which hasn't hit your git repo yet but needs to) and the one to resolve the segfault in your initial patch. I also have these two additional patches that apply on top of your hotunplug branch. With these applied, the code is back to the same basic functionality as the patch I posted originally. However, don't take that to mean it's done ;-) Of note, there are still a couple lingering issues: 1) The kernel won't let us set a device faulty if the array is a non-redundant array type. This is true of mdadm -If $name and also mdadm -f . We need to fix this. I suspect the reason that the kernel doesn't set non-redundant array types as failed in this situation is on the hopes that the underlying device will come back. If it does, and we haven't failed the device yet, then theoretically we could pick up where we left off instead of ever having to fail at all, where as if we fail at all, the entire array goes down. As it turns out, this is a pipe dream. The reason I say that this is a pipe dream is that our continued holding of a reference to the device simply guarantees that even if it came back, it's going to come back with a different device name and major/minor pair, so we will *never* be able to pick up where we left off. So once that device goes away, our array is toast whether we like it or not. 2) IMSM containers are still a bit flaky on their incremental remove/add support. I've been speaking with Dan about this and we've agreed that the fact that they incrementally assemble differently than regular md raid arrays is problematic, especially for udev rules files, and so he was going to work some on the issue (I also have a patch that gets things minimally functional here, but I'm not attaching that to this email). My IMSM rules in the udev file are dracut specific. I don't know which distros will end up switch to dracut from mkinitrd, but we already have for a couple releases of Fedora now. They could be modified for other boot initramfs builders as well, but they basically default imsm array handling to mdadm in the absence of the rd_NO_MDIMSM command line option. -- Doug Ledford GPG KeyID: CFBFF194 http://people.redhat.com/dledford Infiniband specific RPMs available at http://people.redhat.com/dledford/Infiniband