[linux-lvm] Snapshot behavior on classic LVM vs ThinLVM
g.danti at assyoma.it
Thu Mar 1 09:52:10 UTC 2018
On 01/03/2018 09:31, Zdenek Kabelac wrote:
> If the tool wanted to write 1sector to 256K chunk that needed
> 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
> although IMHO still not optimal.
Ah ok, we are speaking about current "can write to allocated chunks only
when full" behavior. This is why I would greatly appreciate a "total
read only mode" on full pool.
Any insight on what ext4 and xfs changed to mitigate the problem? Even a
mailing list link would be very useful ;)
> 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....
In the past, I fiddled with thin_dump to create backups of the metadata
device. Do you think it is a good idea? What somewhat scares me is that,
for thind_dump to work, the metadata device should be manually put in
"snapshot" mode and, after the dump, it had to be unfreezed. What will
happen if I forget to unfreeze it?
> Likely watching Joe's pages (main thin-pool creator) and whatever XFS
> groups is working on....
Again, do you have any links for quick sharing?
> 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....
I thought compression, deduplication, send/receive, etc. where worked on
the framework of stratis. What do you mean with "VDO support"?
Assyoma S.r.l. - www.assyoma.it
email: g.danti at assyoma.it - info at assyoma.it
GPG public key ID: FF5F32A8
More information about the linux-lvm