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

[Zdenek Kabelac <zkabelac@redhat.com>]

Dne 3.3.2018 v 19:17 Xen napsal(a):

>> In the past was argued that putting the entire pool in read-only mode
>> (where *all* writes fail, but read are permitted to complete) would be
>> a better fail-safe mechanism; however, it was stated that no current
>> dmtarget permit that.
> 
> Right. Don't forget my main problem was system hangs due to older kernels, not 
> the stuff you write about now.
> 
>> Two (good) solution where given, both relying on scripting (see
>> "thin_command" option on lvm.conf):
>> - fsfreeze on a nearly full pool (ie: >=98%);
>> - replace the dmthinp target with the error target (using dmsetup).
>>
>> I really think that with the good scripting infrastructure currently
>> built in lvm this is a more-or-less solved problem.
> 
> I agree in practical terms. Doesn't make for good target design, but it's good 
> enough, I guess.

Sometimes you have to settle on the good compromise.

There are various limitation coming from the way how Linux kernel works.

You probably still have 'vision' the block devices KNOWS from where the block 
comes from. I.E. you probably think  thin device is aware block is some 
'write' from  'gimp' made by user 'adam'.  The clear fact is - block layer 
only knows some 'pages' with some sizes needs to be written at some location 
on device - and that's all.

On the other hand all common filesystem in linux were always written to work 
on a device where the space is simply always there. So all core algorithms 
simple never counted with something like 'thin-provisioning' - this is almost 
'fine' since thin-provisioning should be almost invisible - but the problem 
starts to be visible on this over-provisioned conditions.

Unfortunately majority of filesystem never really tested well all those 
'weird' conditions which are suddenly easy to trigger with thin-pool, but 
likely almost never happens on real hdd....

So as said - situation gets better all the time, bugs are fixed as soon as the 
problematic pattern/use case is discovered - that's why it's really important 
users are opening bugzillas and report their problems with detailed 
description how to hit their problem - this really DOES help a lot.

On the other hand it's really hard to do something for users how are
just saying  'goodbye to LVM'....


>> But is someone *really* pushing thinp for root filesystem? I always
>> used it for data partition only... Sure, rollback capability on root
>> is nice, but it is on data which they are *really* important.
> 
> No, Zdenek thought my system hangs resulted from something else and then in 
> order to defend against that (being the fault of current DM design) he tried 
> to raise the ante by claiming that root-on-thin would cause system failure 
> anyway with a full pool.

Yes - this is still true.
It's a core logic of linux kernel and pages caching works.

And that's why it's important to take action *BEFORE* then trying to solve the 
case *AFTER* and hope the deadlock will not happen...


> I was envisioning some other tag that would allow a quotum to be set for every 
> volume (for example as a %) and the script would then drop the volumes with 
> the larger quotas first (thus the larger snapshots) so as to protect smaller 
> volumes which are probably more important and you can save more of them. I am 
> ashared to admit I had forgotten about that completely ;-).

Every user has quite different logic in mind - so really - we do provide 
tooling and user has to choose what fits bets...

Regards

Zdenek