<div dir="ltr">Hi Roman,<br> Sorry for the delay in response.<br><br>* The first problem I saw: After 20 minutes of some basic tests with<br>
file copying gluster mount on all servers became unavailable.<br><br>Do you see any '/core*' files? this means the calls are bailing out, there are three possible reasons.<br> i) because of heavy disk i/o, response is getting delayed, hence the default 'transport-timeout' option is not enough. Try higher values like 120.<br>
<br> ii) a glusterfs process died, hence the clients couldn't connect to the corresponding server process (unlikely in your case a new connection is made again after call bail).<br><br> iii) bug in glusterfs itself. in this case, we would like you to try 1.3.12 (latest 1.3.x release) or wait for another 10days for next pre release of 1.4 branch, which should work fine IMO.<br>
<br><div class="gmail_quote"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><br>
The second problem I see - even with 'option<br>
alu.read-only-subvolumes' gluster remains writing to the specified as<br>
read-only volumes. what could be the reason for this?<br>
</blockquote></div><br>The reason for it is, the 'read-only-subvolumes' option is used for making sure new files are not created on those two subvolumes. But if a file already exists on those subvolumes then it continues to grow. If you don't want any write to happen, you need to use filter.<br clear="all">
<br>Regards,<br>Amar<br><br>-- <br>Amar Tumballi<br>Gluster/GlusterFS Hacker<br>[bulde on #gluster/<a href="http://irc.gnu.org">irc.gnu.org</a>]<br><a href="http://www.zresearch.com">http://www.zresearch.com</a> - Commoditizing Super Storage!<br>
</div>