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

[Gionatan Danti <g.danti@assyoma.it>]

Il 26-04-2017 16:33 Zdenek Kabelac ha scritto:
> But you get correct 'write' error - so from application POV - you get 
> failing
> transaction update/write - so app knows  'data' were lost and should
> not proceed with next transaction - so it's in line with  'no data is
> lost' and filesystem is not damaged and is in correct state
> (mountable).

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.

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