Home | Docs | Forums | Lists | Bugs | Planet | Store | GMN | Get Gentoo!

Full Text Bug Listing

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 an attachment (id=130542) [details]
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.