Il 03-05-2016 16:49 Zdenek Kabelac ha scritto:
Now few people (me included) believe thin volume should error 'ANY'
further write when there was an overprovisioning error on a device and
I'm afraid this can't be solved elsewhere then in target driver.
ATM this thin volume puts filesystem into very complex situation which
does not have 'winning' scenario in number of cases - so we need to
define number of policies.
BUT ATM we clearly communicate - when you run OUT of thin-pool space
it's serious ADMIN failure - and we could only try to lower damage.
Thin-pool overfull CANNOT be compared to writing to a full filesystem
and there is absolutely no guarantee about content of non-flushed
files!
True, but non-synched writes should be always treated as "this item can
be lost if power disappears / system crashes" anyway. On the other
hands, (f)synched writes should already fail immediately if no space can
be allocated from the storage subsystem.
In other words, even with a full data pool filesystem intergrity by
itself should be guaranteed (both by jornaling and fsync), while non
flushed writes "maybe" (if the data segment required was *already*
allocated the writes completes, otherwise it fail as an async lost
page).
For full tmeta things are much worse, as sometime it require
thin_repair. (ps: if you have two free minutes, please see my other
email regarding full tmeta. Thanks in advance).
This is my current understanding; please correct me if I am wrong!
--
Danti Gionatan
Supporto Tecnico
Assyoma S.r.l. - www.assyoma.it
email: g.danti@assyoma.it - info@assyoma.it
GPG public key ID: FF5F32A8
_______________________________________________
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/
