<html><head></head><body>One option would be to use a replicated volume. Then your clients would be able to continue operation in the event of a server loss.<br><br><div class="gmail_quote">On May 1, 2014 2:08:05 AM MDT, Franco Broi <franco.broi@iongeo.com> wrote:<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<pre class="k9mail">On Wed, 2014-04-30 at 21:29 +0200, Michal Pazdera wrote:<br /><blockquote class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #729fcf; padding-left: 1ex;"> What we would like to achieve is the same behavior as NFS or Lustre<br /> does <br /> where running client jobs hang until<br /> the target is back online and then continues in the job.<br /></blockquote><br />This is what we would like too.<br /><br />I think it's reasonable for a job that is in the process of writing a<br />file on a brick that disappears to fail but interrupted reads should be<br />recoverable.<br /><br /><br /><hr /><br />Gluster-users mailing list<br />Gluster-users@gluster.org<br /><a href="http://supercolony.gluster.org/mailman/listinfo/gluster-users">http://supercolony.gluster.org/mailman/listinfo/gluster-users</a><br /></pre></blockquote></div><br>
-- <br>
Sent from my Android device with K-9 Mail. Please excuse my brevity.</body></html>