[Gluster-devel] EAGAIN/EBUSY handling in glusterfs

[Anand Avati]

On Tue, Jan 22, 2013 at 10:39 PM, Shishir Gowda <sgowda at redhat.com> wrote:

> Hi All,
>
> Currently I see that almost all the xlators in glusterfs do not handle
> EAGAIN/EBUSY errors.
>
> Though this should be handled by the applications,


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.


> there are multiple paths where the op's are not performed by the
> applications (but are internal to glusterfs).
>
> Few of these are
>  a. Rebalance
>  b. Replace brick
>  c. Self-heal
>  d. lk's
> etc...
>
> With the proposed snap feature (
> http://www.gluster.org/community/documentation/index.php/Features/snapshot),
> would it not be better to identify such op's inside glusterfs?
>
>
Can you explain more on that? Why is that necessary?

Thanks,
Avati


> Irrespective of the snap feature, I think it is about correctness to
> handle EAGAIN/EBUSY in these code paths.
>
> Please comment.
>
> With regards,
> Shishir
>
>
> _______________________________________________
> Gluster-devel mailing list
> Gluster-devel at nongnu.org
> https://lists.nongnu.org/mailman/listinfo/gluster-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://supercolony.gluster.org/pipermail/gluster-devel/attachments/20130122/201b7a84/attachment-0001.html>