From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mx1.redhat.com (ext-mx05.extmail.prod.ext.phx2.redhat.com [10.5.110.29]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 521AA620A5 for ; Sat, 3 Mar 2018 18:32:28 +0000 (UTC) Received: from smtp2.signet.nl (smtp2.signet.nl [83.96.147.103]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id ECCC083F63 for ; Sat, 3 Mar 2018 18:32:26 +0000 (UTC) Received: from webmail.dds.nl (app2.dds.nl [81.21.136.118]) by smtp2.signet.nl (Postfix) with ESMTP id B415D40C2BE0 for ; Sat, 3 Mar 2018 19:32:25 +0100 (CET) MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Date: Sat, 03 Mar 2018 19:32:25 +0100 From: Xen In-Reply-To: References: <1438f48b-0a6d-4fb7-92dc-3688251e0a00@assyoma.it> <2f9c4346d4e9646ca058efdf535d435e@xenhideout.nl> <5df13342-8c31-4a0b-785e-1d12f0d2d9e8@redhat.com> <6dd12ab9-0390-5c07-f4b7-de0d8fbbeacf@redhat.com> <3831e817d7d788e93a69f20e5dda1159@xenhideout.nl> <0ab1c4e1-b15e-b22e-9455-5569eeaa0563@redhat.com> <51faeb921acf634609b61bff5fd269d4@xenhideout.nl> <4b4d56ef-3127-212b-0e68-00b595faa241@redhat.com> <6dd3a268-8a86-31dd-7a0b-dd08fdefdd55@redhat.com> <9142007eeb745a0f4774710b7c007375@assyoma.it> Message-ID: <1dd5a899e554d5cdc41de41dfa4dde4a@xenhideout.nl> Subject: Re: [linux-lvm] Snapshot behavior on classic LVM vs ThinLVM 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="us-ascii"; format="flowed" To: linux-lvm@redhat.com Zdenek Kabelac schreef op 28-02-2018 22:43: > It still depends - there is always some sort of 'race' - unless you > are willing to 'give-up' too early to be always sure, considering > there are technologies that may write many GB/s... That's why I think it is only possible for snapshots. > You can use rootfs with thinp - it's very fast for testing i.e. > upgrades > and quickly revert back - just there should be enough free space. That's also possible with non-thin. > Snapshot are using space - with hope that if you will 'really' need > that space > you either add this space to you system - or you drop snapshots. And I was saying back then that it would be quite easy to have a script that would drop bigger snapshots first (of larger volumes) given that those are most likely less important and more likely to prevent thin pool fillup, and you can save more smaller snapshots this way. So basically I mean this gives your snapshots a "quotum" that I was asking about. Lol now I remember. You could easily give (by script) every snapshot a quotum of 20% of full volume size, then when 90% thin target is reached, you start dropping volumes with the largest quotum first, or something. Idk, something more meaningful than that, but you get the idea. You can calculate the "own" blocks of the snapshot and when the pool is full you check for snapshots that have surpassed their quotum, and the ones that are past their quotas in the largest numbers you drop first. > But as said - with today 'rush' of development and load of updates - > user do want to try 'new disto upgrade' - if it works - all is fine - > if it doesn't let's have a quick road back - so using thin volume for > rootfs is pretty wanted case. But again, regular snapshot of sufficient size does the same thing, you just have to allocate for it in advance, but for root this is not really a problem. Then no more issue with thin-full problem. I agree, less convenient, and a slight bit slower, but not by much for this special use case. > There are also some on going ideas/projects - one of them was to have > thinLVs with priority to be always fully provisioned - so such thinLV > could never be the one to have unprovisioned chunks.... That's what ZFS does... ;-). > Other was a better integration of filesystem with 'provisioned' > volumes. That's what I was talking about back then...............