<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<div class="moz-cite-prefix">Brian,<br>
<br>
thank you for taking time to explain so well.<br>
<br>
Den 24. okt. 2012 11:56, skrev Brian Candler:<br>
</div>
<blockquote cite="mid:20121024095604.GA1495@nsrc.org" type="cite">
<pre wrap="">On Wed, Oct 24, 2012 at 11:19:13AM +0200, Runar Ingebrigtsen wrote:
</pre>
<blockquote type="cite">
<pre wrap="">Hm, does this mean the whole file will be replicated each time it
changes?
</pre>
</blockquote>
<pre wrap="">Nope. Gluster works at the POSIX filesystem layer, so commands like
"seek(x); write(data)" would replicate as the same commands to both bricks.</pre>
</blockquote>
<br>
Sweet. I love getting insight like this.<br>
<br>
<blockquote cite="mid:20121024095604.GA1495@nsrc.org" type="cite">
<pre wrap="">There used to be an issue with healing, i.e. fixing up replicas after they
have been offline for a while. Prior to gluster 3.3 this involved locking
the whole file, which if it was a VM image would make it unavailable until
healing was complete. Gluster 3.3.x does healing across ranges instead.</pre>
</blockquote>
Does that mean the bauer-power article [1] about how healing fails
is inaccurate?<br>
<br>
My emergency plan, in case of a longer downtime for one peer, was to
remove the peer, format it and add it anew. This was due to the
bauer-power article, but if I understand this now I don't need to
worry? I do take backups, too, of course.<br>
<br>
<blockquote cite="mid:20121024095604.GA1495@nsrc.org" type="cite">
<pre wrap="">However gluster 3.3.x is still not ideal as a VM backing store, because of
the performance issues of going via the kernel and back out through the FUSE
layer. There are bleeding-edge patches to KVM which allow it to use
libglusterfs to talk directly to the storage bricks, staying in userland:
<a class="moz-txt-link-freetext" href="http://lists.gnu.org/archive/html/qemu-devel/2012-06/msg01745.html">http://lists.gnu.org/archive/html/qemu-devel/2012-06/msg01745.html</a></pre>
</blockquote>
I don't think VMware ESX is capable of using the glusterfs-client
anyway.<br>
<br>
<blockquote cite="mid:20121024095604.GA1495@nsrc.org" type="cite">
<pre wrap="">Or you could try using NFS to gluster's NFS server. Or you can boot from a
gluster image, but mount a gluster volume within the VM for application
data.
</pre>
</blockquote>
<br>
My plan is to try running VM's in VMware from NFS.<br>
<br>
[1] <a
href="http://www.bauer-power.net/2012/03/glusterfs-is-not-ready-for-san-storage.html#.UIj1ayExr5U">http://www.bauer-power.net/2012/03/glusterfs-is-not-ready-for-san-storage.html</a><br>
<br>
--<br>
Best Regards<br>
Runar Ingebrigtsen<br>
</body>
</html>