Re: LVM and chain of snapshots

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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

_______________________________________________
linux-lvm mailing list
linux-lvm@redhat.com
https://www.redhat.com/mailman/listinfo/linux-lvm
read the LVM HOW-TO at http://tldp.org/HOWTO/LVM-HOWTO/




[Index of Archives]     [Gluster Users]     [Kernel Development]     [Linux Clusters]     [Device Mapper]     [Security]     [Bugtraq]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]

  Powered by Linux