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 _______________________________________________ linux-lvm mailing list linux-lvm@redhat.com https://www.redhat.com/mailman/listinfo/linux-lvm read the LVM HOW-TO at http://tldp.org/HOWTO/LVM-HOWTO/
