On 1/5/17 3:12 PM, Zdenek Kabelac wrote: > Dne 5.1.2017 v 20:29 Eric Sandeen napsal(a): > > So if I hear all voice correctly now - > > > we now want to let user continue to use such systems and let them > figure out themself something is wrong when they get occasional write > failure and XFS now avoid destruction by shutting down on any journal > failure. No - I'd like to know, specifically, what scenario leads to filesystem corruption when we run out of space in the thin-pool, because I do not expect that result. Anecdotes about "destruction" don't really help. >> (A journal may not be replayable on mount if it needs to allocate more >> thin blocks on replay and is unable to do so, but hat should just fail >> gracefully) > > > I don't have a test sample myself - just some guides how to get to it. > > Use LV and make some thin snapshots. > > Then change various parts of origin - at various moment before pool is out-of-space > > So you will get lots of different scenarios of missing data. (missing /data/ is not "filesystem destruction" - if we're just talking about buffered IO which was never fsynced and does not persist on disk, that is expected with or without thinp on any sort of storage trouble.) > You will mostly not get into those mentioned trouble if you > have just single thinLV and you exhaust thin-pool while using it. > > Games with snapshot are needed. Please formalize that, and I'll be happy to take a look. -Eric -- dm-devel mailing list dm-devel@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/dm-devel
