Re: [2.6.23 PATCH 14/18] dm: netlink add to core

[Alasdair G Kergon]

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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/