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

[Gionatan Danti]

Il 12-05-2017 15:42 Joe Thornber ha scritto:
> On Fri, May 12, 2017 at 03:02:58PM +0200, Gionatan Danti wrote:
>> On 02/05/2017 13:00, Gionatan Danti wrote:
>> >>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.
> 
> I think dm-thin behaviour is fine given the semantics of write
> and flush IOs.
> 
> A block device can complete a write even if it hasn't hit the physical
> media, a flush request needs to come in at a later time which means
> 'flush all IOs that you've previously completed'.  So any software 
> using
> a block device (fs, database etc), tends to generate batches of writes,
> followed by a flush to commit the changes.  For example if there was a
> power failure between the batch of write io completing and the flush
> completing you do not know how much of the writes will be visible when
> the machine comes back.
> 
> When a pool is full it will allow writes to provisioned areas of a thin 
> to
> succeed.  But if any writes failed due to inability to provision then a
> REQ_FLUSH io to that thin device will *not* succeed.
> 
> - Joe

True, but the real problem is that most of the failed flushes will *not* 
bring the filesystem read-only, as both ext4 and xfs seems to go 
read-only only when *metadata* updates fail. As this very same list 
recommend using ext4 with errors=remount-ro on the basis that putting 
the filesystem in a read-only state after any error I the right thing, I 
was somewhat alarmed to find that, as far I can tell, ext4 goes 
read-only on metadata errors only.

So, let me reiterate: can we consider thinlvm + xfs as safe as thinlvm + 
ext4 + errors=remount-ro?
Thanks.

-- 
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