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

[Gionatan Danti]

Il 28-02-2018 22:43 Zdenek Kabelac ha scritto:
> On default - full pool starts to 'error' all 'writes' in 60 seconds.

Based on what I remember, and what you wrote below, I think "all writes" 
in the context above means "writes to unallocated areas", right? Because 
even full pool can write to already-provisioned areas.

> The main problem is - after reboot - this 'missing/unprovisioned'
> space may provide some old data...

Can you elaborate on this point? Are you referring to current behavior 
or to an hypothetical "full read-only" mode?

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

Sure - this was the "more-or-less" part in my sentence.

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

For testing, sure. However for a production machine I would rarely use 
root on thinp. Maybe my reasoning is skewed by the fact that I mostly 
work with virtual machines, so test/heavy upgrades are *not* done on the 
host itself, rather on the guest VM.

> 
> Depends on version of kernel and filesystem in use.
> 
> Note RHEL/Centos kernel has lots of backport even when it's look quite 
> old.

Sure, and this is one of the key reason why I use RHEL/CentOS rather 
than Debian/Ubuntu.

> Backups primarily sits on completely different storage.
> 
> If you keep backup of data in same pool:
> 
> 1.)
> error on this in single chunk shared by all your backup + origin -
> means it's total data loss - especially in case where filesystem are
> using 'BTrees' and some 'root node' is lost - can easily render you
> origin + all backups completely useless.
> 
> 2.)
> problems in thin-pool metadata can make all your origin+backups just
> an unordered mess of chunks.

True, but this not disprove the main point: snapshots are a invaluable 
tool in building your backup strategy. Obviously, if thin-pool meta 
volume has a problem, than all volumes (snapshot or not) become invalid. 
Do you have any recovery strategy in this case? For example, the root 
ZFS uberblock is written on *both* device start and end. Does something 
similar exists for thinp?

> 
> 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....
> Other was a better integration of filesystem with 'provisioned' 
> volumes.

Interesting. Can you provide some more information on these projects?
Thanks.

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