Il 12-09-2017 21:44 matthew patton ha scritto:
Wrong: Qemu/KVM *does* honors write barrier, unless you use
"cache=unsafe".
seems the default is now 'unsafe'.
http://libvirt.org/formatdomain.html#elementsDisks
The default is cache=none
Only if the barrier frame gets passed along by KVM and only if you're
running in "directsync" (or perhaps 'none?') mode there is no
guarantee any of it hit the platter. Let's assume a hypervisor I/O is
ahead of VM 'A's barrier frame, and blows up the thinLV. Then yes it's
possible to propagate the ENOSPACE or other error back to the VM 'A'
to realize that write didn't actually succeed. The rapid failure
cascade across resident VMs is not going to end well either.
fsynched writes that hits a full pool returns EIO to the upper layer
But if that's the only condition it works under they why bother with
XFS on top of thin? You already mentioned that XFS is lousy about
actually detecting underlying block layer problems until much too
late. Just provision the Thin LV and map it directly to the VM. If
your choice of hypervisor is broken, fix it, or choose another that
doesn't have the problem. But really, using ThinLV for guest VM and
asking the hypervisor to not blow up is nuts. Buy a friggin disk. Or
put the onus on try/error where it belongs - inside the guest VM. Why
is that so hard?
KVM is the most valid GPL hypervisor, and libvirt is the virtualization
library of choice.
But I can not fix/implement thin pool/volumes management alone.
You're a web-hosting company and you're trying to duck the laws of
economics and the reality of running a business where other often
clueless people trust you to keep their data intact?
Please, don't elaborate on things you don't know.
I asked a specific question on the linux-lvm list, and (as always) I
learnt something. I don't see any problem in doing that.
Given the screwball way you're going about handling your customer
data, why are you trying to be 'creative'? Storage is your MOST
important and vital capability and naturally your most expensive. Get
real and spend the money. Storage is where you NEVER cut corners and
you NEVER attempt naive optimization efforts.
I'm not quibbling over XFS, you could have picked EXT4 for all I care.
The point is you're trying to get jiggy with customer data to save
pennies. We have a saying, picking up pennies in front of a road
paver. If you're selling capacity you don't have, it's not only
dishonest, but there are proven and well understood ways to do so (eg.
NFS or thin-alloc iSCSI) aimed at a proper storage head that is
properly managed. But ultimately you HAVE to be able to satisfy the
instant demands of all users even if that means they all suddenly wake
up and want to use what you supposedly sold them and entered into a
contract to supply by taking their money.
Again, please don't speak about things you don't know.
I am *not* interested in thin provisioning itself at all; on the other
side, I find CoW and fast snapshots very useful.
Computing/Storage is not a ponzi scheme.
Thanks for remind me that.
--
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/
