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

[Gionatan Danti <g.danti@assyoma.it>]

Il 14-04-2017 10:24 Zdenek Kabelac ha scritto:
> However there are many different solutions for different problems -
> and with current script execution - user may build his own solution -
> i.e.  call
> 'dmsetup remove -f' for running thin volumes - so all instances get
> 'error' device   when pool is above some threshold setting (just like
> old 'snapshot' invalidation worked) - this way user will just kill
> thin volume user task, but will still keep thin-pool usable for easy
> maintenance.
> 

This is a very good idea - I tried it and it indeed works.

However, it is not very clear to me what is the best method to monitor 
the allocated space and trigger an appropriate user script (I understand 
that versione > .169 has %checkpoint scripts, but current RHEL 7.3 is on 
.166).

I had the following ideas:
1) monitor the syslog for the "WARNING pool is dd.dd% full" message;
2) set a higher than 0  low_water_mark and cache the dmesg/syslog 
"out-of-data" message;
3) register with device mapper to be notified.

What do you think is the better approach? If trying to register with 
device mapper, how can I accomplish that?

One more thing: from device-mapper docs (and indeed as observerd in my 
tests), the "pool is dd.dd% full" message is raised one single time: if 
a message is raised, the pool is emptied and refilled, no new messages 
are generated. The only method I found to let the system re-generate the 
message is to deactiveate and reactivate the thin pool itself.

Is this the correct method, or easier/better ones exist?

> But then there is number of cases ending with the case that
> you run out of metadata space that has the maximal size of
> ~16G so you can't even extend it, simply because it's
> unsupported to use any bigger size

Just out of curiosity, in such a case, how to proceed further to regain 
access to data?

And now the most burning question ... ;)
Given that thin-pool is under monitor and never allowed to fill 
data/metadata space, as do you consider its overall stability vs 
classical thick LVM?

Thanks.

-- 
Danti Gionatan
Supporto Tecnico
Assyoma S.r.l. - www.assyoma.it
email: g.danti@assyoma.it - info@assyoma.it
GPG public key ID: FF5F32A8