[linux-lvm] Snapshot behavior on classic LVM vs ThinLVM
zkabelac at redhat.com
Mon May 15 12:50:52 UTC 2017
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?
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
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.
More information about the linux-lvm