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

[Zdenek Kabelac <zkabelac@redhat.com>]

Dne 1.3.2018 v 10:52 Gionatan Danti napsal(a):
> 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 ;)

In general - for extX  it's remount read-only upon error - which works for 
journaled metadata - if you want same protection for 'data' you need to switch 
to rather expensive data journaling mode.

For XFS there is now similar logic where write error on journal stops 
filesystem usage - look far some older message (even here in this list) it's 
been mentioned already few times I guess...

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

Depends on use-case - if you take snapshots of your thin volume, this likely 
has will not help you with recovery at all.

If your thin-volumes are rather standalone only occasionally modified 
'growing' fs  images (so no trimming ;)) - then with this metadata backup 
there can be some small chance you would be able to obtain some 'usable' 
mappings of chunks to block device layout...

Personally I'd not recommend to use this at all unless you know rather 
low-level details how this whole thing works....

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

Unfreezed filesystem is simply not usable...

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

https://github.com/jthornber

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

Clearly  Startis is not a topic for lvm2 at all ;) that's all I'm going to say 
about this....

Regards

Zdenek