Snapshot objects can be created but not activated - and are therefore of little use. Reproducible: Always Steps to Reproduce: 1.Create a snapshot feature object 2.Try to activate it Actual Results: Activation fails, and errors like the following appear in /var/log/evms-engine.log: Sep 08 12:03:52 bristol _5_ Engine: is_object_change_pending: Change pending: Object testsnap needs to be activated. Sep 08 12:03:52 bristol _2_ Snapshot: activate_snapshot_parent: Error activating snapshot testsnap Sep 08 12:03:52 bristol _3_ Engine: activate: Error code 22 activating object testsnap: Invalid argument Sep 08 12:03:52 bristol _2_ Snapshot: activate_snapshot_parent: Error activating snapshot testsnap Sep 08 12:03:52 bristol _3_ Engine: activate: Error code 22 activating object testsnap: Invalid argument Sep 08 12:03:52 bristol _3_ Engine: evms_rediscover: activate() returned error code 22: Invalid argument Expected Results: Activation should succeed, and the snapshot can then be used. The problem is documented, along with a patch to evms that fixes the issue, here: http://www.nabble.com/Snapshots-in-kernel-2.6.19-t3556671.html. I will attach the patch to this bug for convenience. This problem affected all 3 of my machines running EVMS (AMD64 hardened, AMD64 gentoo, and X86 hardened), and the patch fixed it for all of them.
Created attachment 130542 [details, diff] evms-2.5.5-snapshot.patch The aforementioned patch...
I'd like to voice a "please fix!!!" from here too. we are a small hosting company, I have just upgraded a production host for several customer virtual machines, and they are now completely unable to do daily backups. evms-engine.log: _5_ Engine: is_object_change_pending: Change pending: Object dom0snap needs to be activated. _2_ Snapshot: activate_snapshot_parent: Error activating snapshot dom0snap _3_ Engine: activate: Error code 22 activating object dom0snap: Invalid argument _2_ Snapshot: activate_snapshot_parent: Error activating snapshot dom0snap _3_ Engine: activate: Error code 22 activating object dom0snap: Invalid argument _3_ Engine: evms_rediscover: activate() returned error code 22: Invalid argument
I know and I'm really sorry, but I didn't even have time to figure out whether this patch also works with kernels <2.6.19. If someone can assure me that it does, I'll commit the patch right away.
Do you want a test against an older kernel, or against an older version of libdevicemapper? In case it doesn't work, do you expect someone to code a new patch that does? Being pessimistic for a moment and assuming that it won't work, I don't have the ability to create a new patch that does.. But. I think the patch should be applied anyway. Generally speaking, all Linux code is best effort. It calls, it may fail on some API versions, such is life. It's not like dotnet, where you have a development language and loader framework specifically designed to transparently manage multiple API versions with zero effort. Coding a whole "which version of the kernel am I running on?" jungle into EVMS would be much duplicate effort if it had to be done in all libraries. Rather accept that with regards to version management, we'll have to wait till the entire Linux community steps up and does something intelligent, and until then the best we can do is fix things on another level (read: ebuild). With the above paragraph in mind, perhaps we should just update the ebuild to reflect that it can only run on a specific version of the kernel, in case old ones break. Anyway, I'll just go see if I can find where the breaker is... (... hours later ...) The EVMS sources say that everything is done via a call to ioctl(), so I'd guess that the breakage is in the kernel device mapper driver. The RedHat folks have helpfully declined GoogleBot access to the livdevmapper commit archive at http://sources.redhat.com/ml/dm-cvs/, and the integrated search function can't even find itself. git.kernel.org is rather unhelpful too, requiring an exact kernel version be given before it will search for a path or string. Nabble seems to be my friend, though :-). It might have nailed something (with a simple search from the front page no less): http://www.nabble.com/-PATCH-03-25--dm-snapshot%3A-allow-zero-chunk_size-tf2274316.html#a6315352 The above patch is really old (sept 2006), but seems to apply to 2.6.18-rc7. Odd. Either way, the patch above says that the old version accepts anything with at least 4 parameters! So applying the patch should be safe for old kernel versions too - as long as it keeps a minimum of 4 parameters.. (Nasty patch by the way, it rips out code comments explaining more-or-less doubtful logic in the code, leaving just the code to "explain".) Phew. My apologies for writing a novel.
Albert: Which kernel did you use before updating?
kernel before: 2.6.16.18-xen
devzero: So, what have you decided?
Well, I tested evms with gentoo-sources-2.6.16-r13 and EVMS didn't run at all there (somehow the volumes didn't show up in /dev/evms), but there were no particular errors about snapshotting. I'll see that I push out revision bump until the end of the week including the patch. As a security measurement I'll add a warning if a running kernel before 2.6.19 is being detected.
> (somehow the volumes didn't show up in /dev/evms) The snapshot volumes, or every volume? The snapshot volumes are unlinked by evms_activate when the dm table setup fails. (If it's every volume, perhaps something with the udev version) > I'll see that I push out revision bump until the end of the week > including the patch. As a security measurement I'll add a warning > if a running kernel before 2.6.19 is being detected. Beautiful... (Can't wait to get hold of a new version; I just have this feeling that now that backups are down something is going to happen that we wish we had 'em ;-)..)
Finally fixed. Sorry for the delay.
