From mboxrd@z Thu Jan 1 00:00:00 1970 References: <909d4cae-ddd2-3951-eee8-8dec8faa6f22@redhat.com> From: Zdenek Kabelac Message-ID: Date: Wed, 23 Oct 2019 12:46:23 +0200 MIME-Version: 1.0 In-Reply-To: Content-Language: en-US Content-Transfer-Encoding: 8bit Subject: Re: [linux-lvm] exposing snapshot block device Reply-To: LVM general discussion and development List-Id: LVM general discussion and development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , List-Id: Content-Type: text/plain; charset="utf-8"; format="flowed" To: LVM general discussion and development , "Stuart D. Gathman" Cc: =?UTF-8?Q?Dalebj=c3=b6rk=2c_Tomas?= Dne 22. 10. 19 v 18:15 Stuart D. Gathman napsal(a): > On Tue, 22 Oct 2019, Zdenek Kabelac wrote: > >> Dne 22. 10. 19 v 17:29 Dalebj�rk, Tomas napsal(a): >>> But, it would be better if the cow device could be recreated in a faster >>> way, mentioning that all blocks are present on an external device, so that >>> the LV volume can be restored much quicker using "lvconvert --merge" command. > >> I do not want to break your imagination here, but that is exactly the thing >> you can do with thin provisioning and thin_delta tool. > > lvconvert --merge does a "rollback" to the point at which the snapshot > was taken.� The master LV already has current data.� What Tomas wants to > be able to do a "rollforward" from the point at which the snapshot was > taken.� He also wants to be able to put the cow volume on an > extern/remote medium, and add a snapshot using an already existing cow. > > This way, restoring means copying the full volume from backup, creating > a snapshot using existing external cow, then lvconvert --merge instantly > logically applies the cow changes while updating the master > LV. > > Pros: > > "Old" snapshots are exactly as efficient as thin when there is exactly > one.� They only get inefficient with multiple snapshots.� On the other > hand, thin volumes are as inefficient as an old LV with one snapshot. > An old LV is as efficient, and as anti-fragile, as a partition.� Thin > volumes are much more flexible, but depend on much more fragile database > like meta-data. Just few 'comments' - it's not really comparable - the efficiency of thin-pool metadata outperforms old snapshot in BIG way (there is no point to talk about snapshots that takes just couple of MiB) There is also BIG difference about the usage of old snapshot origin and snapshot. COW of old snapshot effectively cuts performance 1/2 if you write to origin. > For this reason, I always prefer "old" LVs when the functionality of > thin LVs are not actually needed.� I can even manually recover from > trashed meta data by editing it, as it is human readable text. On the other hand you can loose COW snapshot at any moment in time if your 'COW' storage is no big enough - this is very different from thin-poo..... Regards Zdenek