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

[Xen]

Gionatan Danti schreef op 22-04-2017 9:14:
> 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.

So a user script can execute dmsetup remove -f on the thin pool?

Oh no, for all volumes.

That is awesome, that means a errors=remount-ro mount will cause a 
remount right?

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

This is what my script is doing of course. It is a bit ugly and a bit 
messy by now, but I could still clean it up :p.

However it does not follow syslog, but checks periodically. You can also 
follow with -f.

It does not allow for user specified actions yet.

In that case it would fulfill the same purpose as > 169 only a bit more 
poverly.

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

This is not my experience on LVM 111 from Debian.

For me new messages are generated when:

- the pool reaches any threshold again
- I remove and recreate any thin volume.

Because my system regenerates snapshots, I now get an email from my 
script when the pool is > 80%, every day.

So if I keep the pool above 80%, every day at 0:00 I get an email about 
it :p. Because syslog gets a new entry for it. This is why I know :p.

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