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.)
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 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.
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.
brassow
Are there any chances to implement snapshot autoextension mechanism,
so it
doesn't require external programs?
_______________________________________________
linux-lvm mailing list
linux-lvm@redhat.com
https://www.redhat.com/mailman/listinfo/linux-lvm
read the LVM HOW-TO at http://tldp.org/HOWTO/LVM-HOWTO/
