On 26/04/2017 18:37, Gionatan Danti wrote:
True, but the case exists that, even on a full pool, an application with multiple outstanding writes will have some of them completed/commited while other get I/O error, as writes to already allocated space are permitted while writes to non-allocated space are failed. If, for example, I overwrite some already-allocated files, writes will be committed even if the pool is completely full. In past discussion, I had the impression that the only filesystem you feel safe with thinpool is ext4 + remount-ro, on the assumption that *any* failed writes will trigger the read-only mode. But from my test it seems that only *failed metadata updates* trigger the read-only mode. If this is really the case, remount-ro really is a mandatory option. However, as metadata can reside on alredy-allocated blocks, even of a full pool they have a chance to be committed, without triggering the remount-ro. At the same time, I thought that you consider the thinpool + xfs combo somewhat "risky", as xfs does not have a remount-ro option. Actually, xfs seems to *always* shutdown the filesystem in case of failed metadata update. Maybe I misunderstood some yours message; in this case, sorry for that. Anyway, I think (and maybe I am wrong...) that the better solution is to fail *all* writes to a full pool, even the ones directed to allocated space. This will effectively "freeze" the pool and avoid any long-standing inconsistencies. Thanks.
Hi Zdeneck, I would *really* to hear back you on these questions. Can we consider thinlvm + xfs as safe as thinlvm + ext4 ? 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/
