[linux-lvm] How to monitor and possibly autoextend snapshots

[Marcin Kałuża]

> -----Original Message-----
> From: linux-lvm-bounces at redhat.com [mailto:linux-lvm-bounces at redhat.com]
> On Behalf Of Jonathan Brassow
> Sent: Wednesday, October 29, 2008 5:17 PM
> To: LVM general discussion and development
> Subject: Re: [linux-lvm] How to monitor and possibly autoextend snapshots
> 
> Firstly, thanks for the fixes to the code.  The last one you mentioned
> (s/"s->ti->table"/"s->table"/) just depends on the kernel you are
> using.  (My patch was against upstream kernel.)
> 
> On Oct 29, 2008, at 9:26 AM, Marcin Kałuża wrote:
> 
> > minor variation is that I needed to use
> >
> > dmsetup wait <device> event_nr
> >
> > because every time the message was signaled,
> > the counter increases and the default for event_nr is 0, not current.
> 
> Yup, I forgot to mention that...  Its done that way so that you can
> keep track if you have handled a particular event or not.
> 
> > Where can I read something about those events and messages? (Apart
> > from the
> > source code itself of course ;)  I like the way it works, but I'd
> > like to
> > know how and why - mainly to know when it can fail ;)
> 
> Yeah... there's not alot of documentation on that - except for some
> small snippets that are sprinkled in the man pages.  Let me explain
> just a little bit more.
> 
> There is inbound and outbound communication to device-mapper targets.
> The inbound (userspace -> kernel) comes in the form of the 'message'
> interface.  Every device-mapper target type (linear, stripe, mirror,
> snapshot, etc) has the option of implementing this function, but is
> not required to - in fact, most do not.  You could use the message
> interface to change device characteristics on the fly.  In our case, I
> implemented the message interface for the snapshot target - giving you
> the ability to tell a particular snapshot to raise an event when it
> gets X full.  Most targets forgo implementing this function because in
> most cases, you can specify a capability that you want when the device
> is created (through the constructor).  However, I think it our case,
> it is preferable to do it our way because we can change and reset when
> we want the notification while the device is live - rather than having
> to suspend and resume with a different constructor string.
> 
> The outbound (kernel -> userspace) communication comes in two forms -
> events and status.  Events (currently) are just a way to signal
> userspace that there is something of significance to be known.  The
> way you get that info is through status.  Events can be raised for any
> number of reasons, so you must read the status to determine if it is
> the event you are looking for.  (For example, mirrors raise events
> when the mirror becomes in-sync or when there is some sort of
> failure.  You would need to get the status to determine which it is
> and what kind of action to take.)


Thanks - his clears things up a bit :)

> 
> > My main concern is what could interfere with this mechanism? Are
> > there any
> > kinds of events and how can I know that this event that occurred is
> > the one
> > I'm waiting for.
> 
> You check the status.  :)
I still didn't figure out how to get the kind of event, that happened...
dmsetup wait -v returns the same thing as "info" and "status" just gives the
size and %usage, but I can live without it :)

 
> > I googled for it, by found no useful info...
> >
> > Is there a way to put it into mainstream lvm at some time (because
> > now I'll
> > have to maintain my custom build kernels...)?
> 
> I think it's a good idea to have this capability, and it has come up
> before; so there is interest.  It can take a while for these things to
> progress, but here is how I see it playing out:
> 
> 1) Get buy-in from the community (especially key players in device-
> mapper, like agk) and have them accept some version of the patch in
> this thread.  I like the patch because it doesn't try to do everything
> in the kernel - setting and resetting the thresholds is done by
> userspace.  This makes it's use very flexible.
> 
> The patch will then go upstream and then come back into other
> distribution kernels.  At this point, you will be able to implement
> your solution, but the features will not be automated.

I never did such things, but I'll go and ask on dm-devel.

> 2) Come to a community consensus as to the arguments and interface
> necessary to specify auto-response to thresholds in snapshots.  Then
> implement that in LVM.  This will take longer because the bulk of the
> work would be done here.
> 
> The patch will then go upstream and then come back into distribution
> LVM packages.
> 
> I'm not sure how long these steps will take - it depends on how
> enthusiastic people are about it.

I've recently found some code for doing it with dmeventd, but somehow I
can't make it work with snapshots (at least not on centos 5.2/64). Again -
I'll go and ask on dm-devel about it.

Thanks for all the help
Martin