[linux-lvm] LVM and chain of snapshots

[linux-lvm] LVM and chain of snapshots

[Марк Коренберг]

[-- Attachment #1: Type: text/plain, Size: 1615 bytes --]

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

[-- Attachment #2: Type: text/html, Size: 2053 bytes --]

Re: [linux-lvm] LVM and chain of snapshots

[Zdenek Kabelac]

Dne 20.1.2016 v 11:37 Марк Коренберг napsal(a):
> 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"
>

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

Re: [linux-lvm] LVM and chain of snapshots

[Марк Коренберг]

[-- Attachment #1: Type: text/plain, Size: 1390 bytes --]

2016-01-20 17:09 GMT+05:00 Zdenek Kabelac <zkabelac@redhat.com>:

> 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

[-- Attachment #2: Type: text/html, Size: 2329 bytes --]

Re: [linux-lvm] LVM and chain of snapshots

[Alexander E. Patrakov]

20.01.2016 17:09, Zdenek Kabelac wrote:
> 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.

-- 
Alexander E. Patrakov

Re: [linux-lvm] LVM and chain of snapshots

[Zdenek Kabelac]

Dne 20.1.2016 v 14:02 Alexander E. Patrakov napsal(a):
> 20.01.2016 17:09, Zdenek Kabelac wrote:
>> 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

Re: [linux-lvm] LVM and chain of snapshots

[Zdenek Kabelac]

Dne 20.1.2016 v 13:54 Марк Коренберг napsal(a):
>
> 2016-01-20 17:09 GMT+05:00 Zdenek Kabelac <zkabelac@redhat.com
> <mailto:zkabelac@redhat.com>>:
>
>     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.

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

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

> 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