192036 2007-09-10 19:57 0000 sys-fs/evms - snapshots don't work with kernel >=2.6.19 2007-12-03 20:13:40 0000 1 1 1 Unclassified Gentoo Linux Applications unspecified All Linux RESOLVED FIXED http://www.nabble.com/Snapshots-in-kernel-2.6.19-t3556671.html P2 normal --- 1 gentoobugs@lspeed.org dev-zero@gentoo.org rosenfield.albert@gmail.com gentoobugs@lspeed.org 2007-09-10 19:57:42 0000 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. gentoobugs@lspeed.org 2007-09-10 20:01:13 0000 Created an attachment (id=130542) evms-2.5.5-snapshot.patch The aforementioned patch... rosenfield.albert@gmail.com 2007-10-26 09:04:20 0000 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 dev-zero@gentoo.org 2007-10-26 09:37:52 0000 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. rosenfield.albert@gmail.com 2007-10-26 14:24:06 0000 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. dev-zero@gentoo.org 2007-10-27 11:12:04 0000 Albert: Which kernel did you use before updating? rosenfield.albert@gmail.com 2007-10-29 18:36:03 0000 kernel before: 2.6.16.18-xen rosenfield.albert@gmail.com 2007-10-30 13:05:29 0000 devzero: So, what have you decided? dev-zero@gentoo.org 2007-10-30 16:21:26 0000 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. rosenfield.albert@gmail.com 2007-10-30 17:18:25 0000 > (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 ;-)..) dev-zero@gentoo.org 2007-12-03 20:13:40 0000 Finally fixed. Sorry for the delay. 130542 2007-09-10 20:01 0000 evms-2.5.5-snapshot.patch evms-2.5.5-snapshot.patch text/plain LS0tIGV2bXMtMi41LjUvZW5naW5lL2RtLXRhcmdldHMuYy5vcmlnCTIwMDUtMTEtMDcgMTU6NDY6 NDEuMDAwMDAwMDAwICswMDAwCisrKyBldm1zLTIuNS41L2VuZ2luZS9kbS10YXJnZXRzLmMJMjAw Ny0wOS0wOCAyMzo1NDoyMy4wMDAwMDAwMDAgKzAxMDAKQEAgLTkyMSwxNCArOTIxLDE0IEBACiAg KgogICogR2VuZXJhdGUgYW4gQVNDSUkgY29uc3RydWN0b3Igc3RyaW5nIGZvciBhIHNuYXBzaG90 IHRhcmdldC4KICAqIEEgc25hcHNob3Qgc3RyaW5nIGhhcyB0aGUgZm9ybToKLSAqICAgPG9yZ19t YWpvcj46PG9yZ19taW5vcj4gPHNuYXBfbWFqb3I+OjxzbmFwX21pbm9yPiA8cHxuPiA8Y2h1bmtf c2l6ZT4gPG9yZ19wYXJlbnRfbWFqb3I+OjxvcmdfcGFyZW50X21pbm9yPgorICogICA8b3JnX21h am9yPjo8b3JnX21pbm9yPiA8c25hcF9tYWpvcj46PHNuYXBfbWlub3I+IDxwfG4+IDxjaHVua19z aXplPgogICoqLwogc3RhdGljIGludCBzbmFwc2hvdF9idWlsZF9wYXJhbXMoZG1fdGFyZ2V0X3Qg KnRhcmdldCkKIHsKIAlkbV90YXJnZXRfc25hcHNob3RfdCAqc25hcHNob3QgPSB0YXJnZXQtPmRh dGEuc25hcHNob3Q7CiAJY2hhciAqZm9ybWF0ID0gKGRtX2dldF92ZXJzaW9uKCkgPT0gMykgPwot CQkJIiV4OiV4ICV4OiV4ICVjICV1ICV4OiV4IiA6Ci0JCQkiJXU6JXUgJXU6JXUgJWMgJXUgJXU6 JXUiOworCQkJIiV4OiV4ICV4OiV4ICVjICV1IiA6CisJCQkiJXU6JXUgJXU6JXUgJWMgJXUiIDsK IAlpbnQgcmMgPSBFTk9NRU07CiAKIAlMT0dfUFJPQ19FTlRSWSgpOwpAQCAtOTM4LDkgKzkzOCw3 IEBACiAJCXNucHJpbnRmKHRhcmdldC0+cGFyYW1zLCA1MCwgZm9ybWF0LAogCQkJIHNuYXBzaG90 LT5vcmlnaW4ubWFqb3IsIHNuYXBzaG90LT5vcmlnaW4ubWlub3IsCiAJCQkgc25hcHNob3QtPnNu YXBzaG90Lm1ham9yLCBzbmFwc2hvdC0+c25hcHNob3QubWlub3IsCi0JCQkgKHNuYXBzaG90LT5w ZXJzaXN0ZW50KSA/ICdwJyA6ICduJywgc25hcHNob3QtPmNodW5rX3NpemUsCi0JCQkgc25hcHNo b3QtPm9yaWdpbl9wYXJlbnQubWFqb3IsCi0JCQkgc25hcHNob3QtPm9yaWdpbl9wYXJlbnQubWlu b3IpOworCQkJIChzbmFwc2hvdC0+cGVyc2lzdGVudCkgPyAncCcgOiAnbicsIHNuYXBzaG90LT5j aHVua19zaXplKTsKIAkJcmMgPSAwOwogCX0KIAo=