On 01/03/2018 09:31, Zdenek Kabelac wrote:
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.
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"?
Thanks.
--
Danti Gionatan
Supporto Tecnico
Assyoma S.r.l. - www.assyoma.it
email: g.danti@assyoma.it - info@assyoma.it
GPG public key ID: FF5F32A8
_______________________________________________
linux-lvm mailing list
linux-lvm@redhat.com
https://www.redhat.com/mailman/listinfo/linux-lvm
read the LVM HOW-TO at http://tldp.org/HOWTO/LVM-HOWTO/
