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

Gionatan Danti g.danti at assyoma.it
Fri May 12 13:02:58 UTC 2017

On 02/05/2017 13:00, Gionatan Danti wrote:
> 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.

Hi all and sorry for the bump...
Anyone with some comments on these questions?


Danti Gionatan
Supporto Tecnico
Assyoma S.r.l. - www.assyoma.it
email: g.danti at assyoma.it - info at assyoma.it
GPG public key ID: FF5F32A8

More information about the linux-lvm mailing list