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

[Zdenek Kabelac]

Dne 14.5.2017 v 22:39 Gionatan Danti napsal(a):
> 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?


Hi

I still think you are mixing apples & oranges together and you expecting 
answer '42' :)

There is simply NO simple answer. Every case has its pros & cons.

There is simply cases where XFS beats Ext4 and there are opposite situations 
as well.

Also you WILL always get WRITE error - if your application doesn't care about 
write error - why do you expect any block-device logic could rescue you ??

Out-of-space thin-pool is simply a device which looks like seriously damaged 
disk where you always read something without any problem and you fail to write 
things here and there.

IMHO both filesystem XFS & Ext4 on recent kernels do work well - but no one 
can say there are no problems at all.

Things are getting better -  but  planning  usage of thin-pool to 'recover' 
overfilled pool is simple BAD planning. You should plan your thin-pool usage 
to NOT run out-of-space.

And last comment I always say -  full thin-pool it not  similar to full 
filesystem where you drop some 'large' file and you are happily working again 
- it's not working this way - and if someone hoped into this - he needs to use 
something else ATM.


Regards


Zdenek