Re: [linux-lvm] Snapshot behavior on classic LVM vs ThinLVM

[Zdenek Kabelac <zkabelac@redhat.com>]

Dne 3.3.2018 v 19:32 Xen napsal(a):
> 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.

I hope it's finally arriving to you that all your wishes CAN be implemented.
It's you to decide what kind of reaction and when it shall happen.

It's really only 'you' to use all the available tooling to do your own 
'dreamed' setup and lvm2  & kernel target provides the tooling.

If you however hope lvm2 will ship 'script' perfectly tuned for Xen system,
it's just you to write and send a patch...

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

I've no idea what you mean by this...

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

ZFS is a 'single' filesystem.

thin-pool is  multi-volume target.

It's approximately like if you would use  your  XFS/ext4 rootfs being placed 
of  ZFS ZVOL device - if you can provide an example, where this 'systems' 
works more stable & better & faster than thin-pool, it's clear bug on 
thin-pool - and your should open bugzilla for this.

Regards

Zdenek