<div dir="ltr"><div><div><div><div><div><div><div><div><div><div>Hi,<br><br></div>I&#39;ve been playing with GlusterFS to test it and I&#39;m quite happy with it for now except few issues I&#39;ll describe here.<br><br></div>I&#39;m running a 3 replica system at work (Ubuntu 14.04 with latest GlusterFS release from PPA) to make sure some data can not vanish in case of hardware failure. They are mounted via FUSE and so far, this is working as expected.<br><br></div>Here are some ideas/thoughts as well as issues :<br><br></div>1/ The concept of &quot;transport.socket.bind-address&quot; is not working properly. I mean, the way it sould work is as bi-directional! If you have a multiple IP addresses on a server pertaining to the same network (ie: 192.168.0.1 and 192.168.0.2) to separate services, you&#39;ll endup with a problem : If you &quot;bind-address&quot; to &quot;xxx.2&quot; for &quot;glusterd&quot;, the second server (ie: having 192.168.0.100 and 192.168.0.101 as IP addresses)  will receive requests at 192.168.0.101 (glusterd bind-address) from... 192.168.0.1! &quot;gluster&quot; should honor this bind-adress option or at least provide a way to use one!<br><br></div>I tried to fiddle the /var/lib/glusterd/peers/&lt;uuid&gt; files but of course it created connection issues as the source IP receiving requests wasn&#39;t the one expected. I understand that and it&#39;s perfectly normal.<br><br></div>So, we definitely need a way, when using &quot;bind-address&quot; to honor it everywhere, be it the listen bind address but also the source IP to use to connect to the peers.<br><br></div>2/ The documentation is scarce and lots of information are really hard to find. I&#39;m new to this project but I spent countless time trying to figure out what options/directives I could use in /etc/glusterfs/glusterd.vol without much success! There&#39;s no place to list every available option and in what context and/or configuration file it can be used! I found about &quot;bind-address&quot; by luck searching for other things :-) Something as complex as GlusterFS should have at least full documentation. I had to look at the source code to see what options could be used by &quot;glusterfs&quot; like the --remote-host mentioned in various places but properly documented nowhere :-(<br><br></div>3/ There should be a way to define &quot;default properties&quot; (like a profile) for each new created volume. For each volume I created during my tests, I had to manually remove NFS support as well as set/modify other options. This is painful if you create more than one volume. I use pure NFSv4 on my network and I don&#39;t need legacy NFS implementations fired up by default without knowing, messing up with &quot;rpcbind&quot; and leading to the utterly annoying &quot;socket failed&quot; bug - <a href="https://bugzilla.redhat.com/show_bug.cgi?id=1199936">https://bugzilla.redhat.com/show_bug.cgi?id=1199936</a> - spamming the logs when disabling NFS support. The Unix philosophy, unlike the Windows world, is to keep the opened services to a minimum and let the admin decide which one he/she desires to use.<br><br></div>4/ The logging system is overwhelming! Any admin wants/needs logs to figure out what&#39;s wrong but GlusterFS is just too much! I logs everything, producing a huge load of information which actually is way counter productive as it totally drowns useful information under a lot of not-so-useful information. Besides, &quot;diagnostics.client-log-level&quot; and &quot;diagnostics.brick-log-level&quot;, I found no other way to reduce a bit the logs. <br><br></div>The worst of all being &quot;gluster&quot; itself ! Just launch it, get the prompt &quot;gluster&gt; &quot; and do nothing. Now have a look to /var/log/glusterfs/cli.log and be frightened by a trace-level log filling up at a 3~8 entries per second!<br><div><br></div><div>That&#39;s it for now. All of this sounds like big criticism but in fact, I mention them so they could be addressed because as far as functionality goes, my first attempt with GlusterFS is quite nice :-)<br></div><div><div><div><div><div><div><div><div><div><div><div><div><br clear="all"><br>-- <br><div class="gmail_signature">Unix _IS_ user friendly, it&#39;s just selective about who its friends are.</div>
</div></div></div></div></div></div></div></div></div></div></div></div></div>