From mboxrd@z Thu Jan 1 00:00:00 1970 References: <1438f48b-0a6d-4fb7-92dc-3688251e0a00@assyoma.it> <2f9c4346d4e9646ca058efdf535d435e@xenhideout.nl> <5df13342-8c31-4a0b-785e-1d12f0d2d9e8@redhat.com> <6dd12ab9-0390-5c07-f4b7-de0d8fbbeacf@redhat.com> <3831e817d7d788e93a69f20e5dda1159@xenhideout.nl> <0ab1c4e1-b15e-b22e-9455-5569eeaa0563@redhat.com> <51faeb921acf634609b61bff5fd269d4@xenhideout.nl> <4b4d56ef-3127-212b-0e68-00b595faa241@redhat.com> <6dd3a268-8a86-31dd-7a0b-dd08fdefdd55@redhat.com> <9142007eeb745a0f4774710b7c007375@assyoma.it> <0a322a6f355a0744427f2a7a45162c81@assyoma.it> From: Zdenek Kabelac Message-ID: <1be887bb-d86f-5896-1c19-844864c41ba2@redhat.com> Date: Thu, 1 Mar 2018 12:23:44 +0100 MIME-Version: 1.0 In-Reply-To: Content-Language: en-US Content-Transfer-Encoding: 8bit Subject: Re: [linux-lvm] Snapshot behavior on classic LVM vs ThinLVM Reply-To: LVM general discussion and development List-Id: LVM general discussion and development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , List-Id: Content-Type: text/plain; charset="utf-8"; format="flowed" To: Gionatan Danti Cc: LVM general discussion and development 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