On Thu, Jul 12, 2007 at 01:37:43PM -0600, Eric W. Biederman wrote: > This of course assumes things are a good fit or the other pieces > can be made to be a good fit. Currently I don't see the what makes > device mapper's events not fit the existing models, and I don't > see it in the description for this patch why we need to invent > something new. The existing event protocol used by device-mapper is trivial. It just lets kernel device-mapper say to userspace 'Something happened on mapped device X in which you might be interested: Check it out!'. Userspace then runs various checks to work out what happened and decide whether any action should be taken. Though simple, in practice this often proves very inefficient. We want to change the mechanism so device-mapper can pass an arbitrary small payload to userspace to tell it exactly what happened immediately so it no longer needs to waste time probing for things that could have happened but kernel device-mapper knows didn't. These netlink patches are the first attempt to put such a mechanism in place for a few specific multipath conditions. Sure, we *could* shoe-horn this into extended dm ioctls but I see that as a last resort if we can't make an existing mechanism do what we need. Examples of events raised against device-mapper block devices to switch to whichever new mechanism is chosen: - a new dm table has gone live (payload holds some basic info about the new table) - the dm device name has just been changed (new name in payload) - a path in a multipath table has been marked as failed e.g. after an I/O failure (payload says which path) - a failed path in a multipath table has been reenabled (payload says which path) - a specific group of multipath paths has been bypassed (payload says which group) - I/O is being directed to a different group of multipath paths (payload says which group) - mirror recovery is complete - a mirror's log device has failed - a snapshot has been marked invalid (payload indicates reason) Depending on the context, the events are caught by a userspace device-mapper process (sometimes a long-lived daemon) - one that is often locked in memory with preallocated buffers all set to process the information and resolve the problem etc. Alasdair -- agk@xxxxxxxxxx -- dm-devel mailing list dm-devel@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/dm-devel
