Manage: Inform udev about device removal when stopping
Hi Sebastian,
while it's true in general that a 'change' event should not be sent when a device is being removed or deleted, sending a 'remove' event from userspace is most definitely wrong, too.
'remove' events should be generated from the kernel whenever a device disappears from sysfs; it should never be generated from userspace (as the device will still be present in sysfs).
Cheers,
Hannes
Signature · 9 lines
Dr. Hannes Reinecke Teamlead Storage & Networking [email protected] +49 911 74053 688 SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg GF: F. Imendörffer, J. Smithard, J. Guild, D. Upmanyu, G. Norton HRB 21284 (AG Nürnberg) -- To unsubscribe from this list: send the line "unsubscribe linux-raid" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
Quoted 8 lines · Hannes Reinecke
Hi Sebastian,
while it's true in general that a 'change' event should not be sent when a device is being removed or deleted, sending a 'remove' event from userspace is most definitely wrong, too.
'remove' events should be generated from the kernel whenever a device disappears from sysfs; it should never be generated from userspace (as the device will still be present in sysfs).
Hi Hannes,
thanks for your comment! Only few people actually stop md devices without rebooting. As a hotfix for running systems it is definitely the best solution for us at PB to do it in mdadm. Mdadm knows in this situation that stopping worked.
But I'm also fine with dropping the support for kernels prior to 2.6.28 and the event sending in mdadm completely for the mainline. Sending the kernel patch to linux-stable is kind of useless if mdadm still sends the change event.
So your vote seems to be dropping the udev event sending in mdadm and going for the kernel change.
I'll wait for other comments or votes for the preferred solution.
Cheers,
Sebastian