[linux-lvm] Snapshot behavior on classic LVM vs ThinLVM
zkabelac at redhat.com
Thu Mar 1 08:31:02 UTC 2018
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.
>> 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....
More information about the linux-lvm