Hannes Reinecke wrote: > Michael Reed wrote: >> James Bottomley wrote: >>> Since the rest of >>> our infrastructure is already event driven, or migrating that way, I >>> really don't see value in introducing an anomaly like this purely for >>> fibre channel. >> It's tough on fibre channel, being first. :) >> >> Among the benefits of this patch is the purchase of time. With the fc >> infrastructure the way it is, you're assured of forcing developers to >> "publish or perish". That may be the intended desire. It just doesn't >> seem fair to the users who have to deal with this. It makes sense to >> me to implement the event driven infrastructure in such a way that >> it's more complete when released. If infrastructure is going to be >> removed, then "applications" have to be adjusted to accommodate this. >> It shouldn't be, oh by the way, your driver/app is now broken, hurry up >> and fix it or your users will complain. [End Of Rant]. My patch >> buys time. Change the default so that the remove on disconnect has >> to be consciously overridden. Remove the variable when the supporting >> infrastructure is in place. Put out a message indicating that the >> option of not removing the infrastructure is "going away" in a future >> release. Provide an orderly transition. Insure domestic tranquility. >> Promote the general welfare. :) I'm happy to adjust the patch >> to accommodate any of these suggestions if they are deemed acceptable. >> > And I can only _strongly_ agree with Mike here. > Yes, the infrastructure is moving towards dynamic device configuration. > But no, we're not there yet. Not by a long way. > Neither of the current volume managers (ie LVM2, EVMS, and even md to > some extend) are capable of dynamic reconfiguration. I do not think DM based volume manager will work at all if all devices in a DM table are removed at the same time temporarily. For dm-multipath we would end up with no dm device and then the user will have to remount the FS. Does the kobject_uevent use also have problems? I guess GFP_KERNEL allocations will not fail, but if all the devices are dm-multipath devices is there the possibility that the GFP_KERNEL allocation will wait forever or is there a way for it work eventually? Is this one of those things we are waiting for the VM guys to fix, or do modify the uevent code or just not get into it by never removing and readding the devices? - : send the line "unsubscribe linux-scsi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
