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

[Zdenek Kabelac]

Dne 1.3.2018 v 08:14 Gionatan Danti napsal(a):
> 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.

yes

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

If the tool wanted to write  1sector  to 256K chunk that needed provisioning,
and provisioning was not possible - after reboot - you will still see
the 'old' content.

In case of filesystem, that does not stop upon 1st. failing write you then can 
see a potential problem since  fs could issue writes - where halve of them
were possibly written and other halve was errored - then you reboot,
and that 'error' halve is actually returning 'some old data' and this can make 
filesystem seriously confused...
Fortunately both ext4 & xfs both have now correct logic here for journaling,
although IMHO still not optimal.

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

Unfortunately losing root blocks on thin-pool metadata is a big problem.
That's why metadata should be rather on some resilient fast storage.
Logic of writing should not let data corrupt (% broken kernel).

But yes - there is quite some room for improvement in thin_repair tool....

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

Likely watching Joe's pages (main thin-pool creator) and whatever XFS groups 
is working on....

Also note - we are going to integrate VDO support - which will be a 2nd. way 
for thin-provisioning with different set of features - missing snapshots, but 
having compression & deduplication....

Regards

Zdenek