You have to remember that when you are writing with NFS you&#39;re writing to one node, where as your gluster setup below is copying the same data to two nodes;  so you&#39;re doubling the bandwidth.  Dont expect nfs like performance on writing with multiple storage bricks.  However read performance should be quite good.<div>
<br></div><div>liam<br><br><div class="gmail_quote">On Wed, Jul 8, 2009 at 5:22 AM, Hiren Joshi <span dir="ltr">&lt;<a href="mailto:josh@moonfruit.com">josh@moonfruit.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
Hi,<br>
<br>
I&#39;m currently evaluating gluster with the intention of replacing our<br>
current setup and have a few questions:<br>
<br>
At the moment, we have a large SAN which is split into 10 partitions and<br>
served out via NFS. For gluster, I was thinking 12 nodes to make up<br>
about 6TB (mirrored so that&#39;s 1TB per node) and served out using<br>
gluster. What sort of filesystem should I be using for the nodes<br>
(currently on ext3) to give me the best performance and recoverability?<br>
<br>
Also, I setup a test with a simple mirrored pair with a client that<br>
looks like:<br>
volume glust3<br>
 type protocol/client<br>
 option transport-type tcp/client<br>
 option remote-host glust3<br>
 option remote-port 6996<br>
 option remote-subvolume brick<br>
end-volume<br>
volume glust4<br>
 type protocol/client<br>
 option transport-type tcp/client<br>
 option remote-host glust4<br>
 option remote-port 6996<br>
 option remote-subvolume brick<br>
end-volume<br>
volume mirror1<br>
  type cluster/replicate<br>
  subvolumes glust3 glust4<br>
end-volume<br>
volume writebehind<br>
  type performance/write-behind<br>
  option window-size 1MB<br>
  subvolumes mirror1<br>
end-volume<br>
volume cache<br>
  type performance/io-cache<br>
  option cache-size 512MB<br>
  subvolumes writebehind<br>
end-volume<br>
<br>
<br>
I ran a basic test by writing 1G to an NFS server and this gluster pair:<br>
[root@glust1 ~]# time dd if=/dev/zero of=/mnt/glust2_nfs/nfs_test<br>
bs=65536 count=15625<br>
15625+0 records in<br>
15625+0 records out<br>
1024000000 bytes (1.0 GB) copied, 1718.16 seconds, 596 kB/s<br>
<br>
real    28m38.278s<br>
user    0m0.010s<br>
sys     0m0.650s<br>
[root@glust1 ~]# time dd if=/dev/zero of=/mnt/glust/glust_test bs=65536<br>
count=15625<br>
15625+0 records in<br>
15625+0 records out<br>
1024000000 bytes (1.0 GB) copied, 3572.31 seconds, 287 kB/s<br>
<br>
real    59m32.745s<br>
user    0m0.010s<br>
sys     0m0.010s<br>
<br>
<br>
With it taking almost twice as long, can I expect this sort of<br>
performance degradation on &#39;real&#39; servers? Also, what sort of setup<br>
would you recommend for us?<br>
<br>
Can anyone help?<br>
Thanks,<br>
Josh.<br>
<br>
_______________________________________________<br>
Gluster-users mailing list<br>
<a href="mailto:Gluster-users@gluster.org">Gluster-users@gluster.org</a><br>
<a href="http://zresearch.com/cgi-bin/mailman/listinfo/gluster-users" target="_blank">http://zresearch.com/cgi-bin/mailman/listinfo/gluster-users</a><br>
</blockquote></div><br></div>