On Fri, Nov 29, 2013 at 6:56 PM, Sander Eikelenboom <address@hidden> wrote:
Erhmm well that's why glusterfs is momentarily in between :-)
I have a LVM volume "shared_data" on the host .. which I export as a brick with glusterfs.
Multiple VM's mount this brick over the tcp/ip transport, and all seems to go well with locking.
I have looked at GFS2 and Ceph as well, though glusterfs served me well.
It's just to see if it would be possible to eliminate the use of the tcp/ip transport for
the VM's that use Qemu to reduce that overhead.
Okay, this should be on gluster-users first of all.
Second of all, the regular fuse mount and libgfapi both use tcp/ip.
Second of all, the regular fuse mount and libgfapi both use tcp/ip.
Thirdly, you have to understand the difference between a block device (qemu-libgfapi integration) and a gluster fuse mount (a filesystem). Read about those a bit more, and hopefully this will make my comments make sense.
Fourthly, it's not a GFS2 vs. Gluster question. They are DIFFERENT technologies, not competing technologies. GlusterFS is one piece. If you _really_ want to have a shared block device, be used for a mounted filesystem, then the individual writers _need_ to coordinate. That's what GFS2+cman does. Also, I've never tested GlusterFS through qemu for a GFS2 fs. I'd be curious to hear if it works without bugs though.
Fifthly?, it's dinner time!
Cheers