Discussion:
[linux-lvm] LVM and chain of snapshots
Марк Коренберг
2016-01-20 10:37:12 UTC
Permalink
I am aware that this subject was raised in mailing lists, but I haven't
found an obvious solution there.

Why not to add an option to lvcreate when creating snapshots, to switch
origin and snapshot ?

I mean that while (in this mode) creating snapshot named xxx of volume name
yyy, the following should be done:

1. xxx-real dmsetup volume is created with identical table as in yyy
2. yyy-cow dmsetup volume is created to store snapshot data
3. yyy is switched to table "snapshot xxx-real yyy-cow"
4. xxx created as "snapshot-origin xxx-real"

So, if FS was mounted from yyy, after creating such snapshot, all writes on
that FS should go to yyy-cow actually.

Note, performance of the writes to yyy will not be affected (comparing to
creating generic snapshot as usual).

At this stage, picture is the following:

[original=linear=xxx] -> [snapshot=yyy referring xxx (mounted FS)]

Next, user may decide to create new snapshot named zzz of volume yyy in
this new mode. After that picture will look like:

[original=linear=xxx] -> [snapshot=zzz referring xxx] -> [snapshot=yyy
referring zzz (mounted FS)]

Note, that having plenty snapshots in that mode will not affect write
performance of yyy. Yes, performance of read operations may slightly suffer
since require to lookup chain of snapshots, but this is much less
performance impact comparing to writes to original when plenty snapshots
created (in generic mode).

Next, this structure allows merging (i.e. zzz into xxx for example)
snapshots in chain easily.

P.S. we may call this operation "split origin" instead of "create snapshot"
--
Segmentation fault
Zdenek Kabelac
2016-01-20 12:09:30 UTC
Permalink
I am aware that this subject was raised in mailing lists, but I haven't found
an obvious solution there.
Why not to add an option to lvcreate when creating snapshots, to switch origin
and snapshot ?
I mean that while (in this mode) creating snapshot named xxx of volume name
1. xxx-real dmsetup volume is created with identical table as in yyy
2. yyy-cow dmsetup volume is created to store snapshot data
3. yyy is switched to table "snapshot xxx-real yyy-cow"
4. xxx created as "snapshot-origin xxx-real"
Most development now goes to 'thin' snapshot support where it
doesn't really matter what is called origin and what is the snapshot.

So with thin you get this functionality for free.

For current old-snaphot I'm now working on 'resize' support - once this
is solved we may look at this issue.

But from first look it doesn't look like it brings anything 'new' to the table.

The main thing is - what is expected state - and you seems to be targeting
for the case, where 'snapshot' is the playground which is going to be
removed after playing.

However from higher-level logic - you cannot --merge snapshot back to origin
without unmounting both origin and snapshot.

So there is possibly advantage where you can 'drop' snapshot,
but you can't do that without unmount first - and once you unmount,
you could equally run --merge and have instant access to merged snapshot
(where merging runs in background).

Anwyay - if you think there is 'valid' use-case - feel free to open [RFE]
bugzilla request at bugzilla.redhat.com for lvm2 package.

And specify use-case you want to see supported.
IMHO for best perfomance you should reorient to thin-provisioing,
since old-snapshot are in its nature not really improvable.
Note, that having plenty snapshots in that mode will not affect write
performance of yyy. Yes, performance of read operations may slightly suffer
since require to lookup chain of snapshots, but this is much less performance
impact comparing to writes to original when plenty snapshots created (in
generic mode).
Using lots of old-snaphosts is very bad plan - really time to look at
thin-provisioning....
Old-snaps are not going to scale.....

Regards

Zdenek
Zdenek Kabelac
2016-01-20 13:11:55 UTC
Permalink
Post by Zdenek Kabelac
Using lots of old-snaphosts is very bad plan - really time to look at
thin-provisioning....
Old-snaps are not going to scale.....
Well, I have already tried using lots of thin snapshots on my PC, in a context
different from what Mark wants. Namely, my snapshots were created by Snapper,
hourly.
Thin snapshots may indeed scale well for reads and writes, but currently they
don't scale at all for the initial activation. The problem is that "vgchange
-ay" and "vgchange -an", by default, run "thin_check", and the more snapshots
I have, the more it takes for "thin_check" to finish. With 1 snapshot, it is
quick enough so that I don't notice. But with, say, 200 snapshots (some of
which include creation of an iso image), it takes more than 1.5 minutes - more
than the initramfs (or myself) is going to wait during the boot process.
Well the execution of thin_check is 'rather' security feature.
It's been added to capture possible errors of kernel driver.
I guess now we are possibly in the age where deep checking might no longer be
necessary.

So if you feel the time spend on thin_checking doesn't pay-off - you can try
to add option '--skip-mappings' (see lvm.conf field global/thin_check_options)

Also you really should not keep 200 snapshots if you don't need them.
So probably try to maintain your snapshots better (drop unneeded ones...)

And final note - I do not believe activation of multi-gigabyte old-snapshot is
going to give you any better results - since reading of old metadata is
actually much slower then management of thin-pool & thin_check - just try it....

It's fairly naive to expect old-snaps will do any better job when we are
talking about 200 snaps.

Also there is no support for snaps of snaps of snaps with old-snapshot,
so it's not even comparable....

Regards

Zdenek
Марк Коренберг
2016-01-20 12:54:05 UTC
Permalink
Post by Zdenek Kabelac
ed sta
Thanks for the response, but I do not understand how thin-provisioning is
related to question i'm asking.

As far as I understand, if 20 snapshots are created even in
thin-provisioning mode, write to origin will be converted
to 21 writes. Does not it ? My scenario mean that no write multiplication
occurs while making "normal" operations in
userspace (i.e. not writing to snapshots, while origin is under heavy
write-load). Also, my scenario adds functionality
of "snapshot of snapshot" easily. The case I'm trying to discuss is
something like chain of qcow2 files used to make
live snapshots in KVM.

Use case: having such snapshot every day. And after snapshot count exceed
30, meld first snapshot into it's origin.
This operation should be possible without any unmounting. After merging,
that snapshot should contain empty diff
and so may be eliminated from chain via replacing dmsetup tables.

If someone wants to rollback - he just remove some tail of the chain +
rename last item, or, create generic snapshot
from any colume in chain, or just use some point in chain. everything will
work as expected.

In other words, my proposal is not connected to low-level things in LVM.
Yes, all snapshots I describe can be
thin-provisioned. Just minimal logic, CLI and XML should extended.
--
Segmentation fault
Zdenek Kabelac
2016-01-20 14:20:25 UTC
Permalink
Post by Zdenek Kabelac
ed sta
Thanks for the response, but I do not understand how thin-provisioning is
related to question i'm asking.
As far as I understand, if 20 snapshots are created even in thin-provisioning
mode, write to origin will be converted
to 21 writes. Does not it ? My scenario mean that no write multiplication
occurs while making "normal" operations in
userspace (i.e. not writing to snapshots, while origin is under heavy
write-load). Also, my scenario adds functionality
of "snapshot of snapshot" easily. The case I'm trying to discuss is something
like chain of qcow2 files used to make
live snapshots in KVM.
You cannot chain old-snaps this way (you cannot map old-snap over old-snap)
And no - it's not easy to add one.
So your proposal would have worked for exactly 1 level
e.g. you continue to write to snap - and you keep origin intact,
but you cannot map another 'snap' over this snap.

lvm2 is currently incapable of doing this - and it's fairly nontrivial to
support this - and especially when we have thin-provisioning, noone is
currently planning to extend old snapshot with such complicated feature.
Post by Zdenek Kabelac
Use case: having such snapshot every day. And after snapshot count exceed 30,
meld first snapshot into it's origin.
So you would need 30 chained snaps....
And after 30 of them - you actually would need merging them - quite complicated...
Post by Zdenek Kabelac
This operation should be possible without any unmounting. After merging, that
snapshot should contain empty diff
and so may be eliminated from chain via replacing dmsetup tables.
It's much better to directly update 'origin' and just drop no longer needed
snapshot.

The only major issue is - running 30 old snapshot it just not suitable for
any use...
Post by Zdenek Kabelac
In other words, my proposal is not connected to low-level things in LVM. Yes,
all snapshots I describe can be
thin-provisioned. Just minimal logic, CLI and XML should extended.
In other words - you just described how thin-provisioning works
and there is no reason to reinvent the wheel again :)

So please for this use-case switch to thin-provisioning.

Regards

Zdenek

Loading...