<br><br><div class="gmail_quote">On Wed, Jan 23, 2013 at 1:34 AM, Shishir Gowda <span dir="ltr"><<a href="mailto:sgowda@redhat.com" target="_blank">sgowda@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hi Avati,<br>
<br>
One of the possible scenarios is someone taking a lvm snap of the backend.<br>
<br></blockquote><div><br></div><div>Can you describe in more detail exact operations for which LVM snap returns EAGAIN or EINTR? EINTR in posix is best retried in posix level. However I'm not sure if LVM snapshote actually makes the disk filesystem return these non standard errors for any reason. Can you give an example strace of this happening?</div>
<div><br></div><div>Avati</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
few eg:<br>
DHT's rebalance: we would not retry a migration if case we got an error EAGAIN or even EINTR.<br>
Does self-heal retry healing if the error was EAGAIN or EINTR?<br>
<br>
These are just few I can think about.<br>
<br>
When snap feature becomes supported (refer to wiki link in previous page), few ops' would be blocked while snap is in progress.<br>
<br>
If we decide to provide complete snap in the future (not just crash-consistent), then in all probability all fops will be blocked.<br>
<br>
Do we guarantee all op's(triggered internally) that fail will be re-triggered? Or are we guaranteeing a state from which we can recover completely?<br>
<br>
With regards,<br>
Shishir<br>
<div class="im"><br>
----- Original Message -----<br>
From: "Anand Avati" <<a href="mailto:anand.avati@gmail.com">anand.avati@gmail.com</a>><br>
To: "Shishir Gowda" <<a href="mailto:sgowda@redhat.com">sgowda@redhat.com</a>><br>
Cc: <a href="mailto:gluster-devel@nongnu.org">gluster-devel@nongnu.org</a><br>
Sent: Wednesday, January 23, 2013 1:23:09 PM<br>
Subject: Re: [Gluster-devel] EAGAIN/EBUSY handling in glusterfs<br>
<br>
<br>
<br>
<br>
On Tue, Jan 22, 2013 at 10:39 PM, Shishir Gowda < <a href="mailto:sgowda@redhat.com">sgowda@redhat.com</a> > wrote:<br>
<br>
<br>
Hi All,<br>
<br>
Currently I see that almost all the xlators in glusterfs do not handle EAGAIN/EBUSY errors.<br>
<br>
Though this should be handled by the applications,<br>
<br>
<br>
If by "handle by application" you meant "handled by retrying syscall by application", that is not completely true. More generally it is true for EINTR, and some places for EAGAIN (i.e when used on non-blocking pollable file descriptors like sockets - which specifically does NOT include filesystem for regular read/write). EBUSY almost always does not suggest a poll/retry to the application.<br>
<br>
<br>
there are multiple paths where the op's are not performed by the applications (but are internal to glusterfs).<br>
<br>
Few of these are<br>
a. Rebalance<br>
b. Replace brick<br>
c. Self-heal<br>
d. lk's<br>
etc...<br>
<br>
</div>With the proposed snap feature ( <a href="http://www.gluster.org/community/documentation/index.php/Features/snapshot" target="_blank">http://www.gluster.org/community/documentation/index.php/Features/snapshot</a> ), would it not be better to identify such op's inside glusterfs?<br>
<div class="HOEnZb"><div class="h5"><br>
<br>
<br>
<br>
Can you explain more on that? Why is that necessary?<br>
<br>
<br>
Thanks,<br>
Avati<br>
<br>
<br>
Irrespective of the snap feature, I think it is about correctness to handle EAGAIN/EBUSY in these code paths.<br>
<br>
Please comment.<br>
<br>
With regards,<br>
Shishir<br>
<br>
<br>
_______________________________________________<br>
Gluster-devel mailing list<br>
<a href="mailto:Gluster-devel@nongnu.org">Gluster-devel@nongnu.org</a><br>
<a href="https://lists.nongnu.org/mailman/listinfo/gluster-devel" target="_blank">https://lists.nongnu.org/mailman/listinfo/gluster-devel</a><br>
<br>
</div></div></blockquote></div><br>