[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

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.)

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?



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]