<div dir="ltr">GFAPI observes ENOENT with glfs_stat() - so the fix is necessary. </div><div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, Dec 18, 2013 at 9:55 PM, Pranith Kumar Karampuri <span dir="ltr"><<a href="mailto:pkarampu@redhat.com" target="_blank">pkarampu@redhat.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5"><br>
<br>
----- Original Message -----<br>
> From: "Vijay Bellur" <<a href="mailto:vbellur@redhat.com">vbellur@redhat.com</a>><br>
> To: "Pranith Kumar Karampuri" <<a href="mailto:pkarampu@redhat.com">pkarampu@redhat.com</a>>, "Venkatesh Somyajulu" <<a href="mailto:vsomyaju@redhat.com">vsomyaju@redhat.com</a>><br>
> Cc: <a href="mailto:gluster-devel@nongnu.org">gluster-devel@nongnu.org</a><br>
> Sent: Thursday, December 19, 2013 9:59:01 AM<br>
> Subject: Re: [Gluster-devel] upstream: Symbolic link not getting healed<br>
><br>
> On 12/19/2013 07:58 AM, Pranith Kumar Karampuri wrote:<br>
> > hi,<br>
> > I used the following test to figure out the bad commit.<br>
> > #!/bin/bash<br>
> ><br>
> > . $(dirname $0)/../include.rc<br>
> > . $(dirname $0)/../volume.rc<br>
> ><br>
> > function trigger_mount_self_heal {<br>
> > find $M0 | xargs stat<br>
> > }<br>
> ><br>
> > cleanup;<br>
> ><br>
> > TEST glusterd<br>
> > TEST pidof glusterd<br>
> > TEST $CLI volume create $V0 replica 2 $H0:$B0/${V0}{0,1}<br>
> > TEST $CLI volume set $V0 cluster.background-self-heal-count 0<br>
> > TEST $CLI volume start $V0<br>
> > TEST glusterfs --volfile-id=/$V0 --volfile-server=$H0 $M0 --use-readdirp=no<br>
> > --attribute-timeout=0 --entry-timeout=0<br>
> > TEST touch $M0/a<br>
> > TEST kill_brick $V0 $H0 $B0/${V0}0<br>
> > TEST ln -s $M0/a $M0/s<br>
> > TEST ! stat $B0/${V0}0/s<br>
> > TEST stat $B0/${V0}1/s<br>
> > TEST $CLI volume start $V0 force<br>
> > EXPECT_WITHIN 20 "Y" glustershd_up_status<br>
> > EXPECT_WITHIN 20 "1" afr_child_up_status_in_shd $V0 0<br>
> > TEST $CLI volume heal $V0 full<br>
> > TEST trigger_mount_self_heal<br>
> > TEST stat $B0/${V0}0/s<br>
> > TEST stat $B0/${V0}1/s<br>
> > cleanup<br>
> ><br>
> > According to git bisect run, the commit which introduced this problem is:<br>
> ><br>
> > 837422858c2e4ab447879a4141361fd382645406<br>
> > commit 837422858c2e4ab447879a4141361fd382645406<br>
> > Author: Anand Avati <<a href="mailto:avati@redhat.com">avati@redhat.com</a>><br>
> > Date: Thu Nov 21 06:48:17 2013 -0800<br>
> ><br>
> > core: fix errno for non-existent GFID<br>
> ><br>
> > When clients refer to a GFID which does not exist, the errno to<br>
> > be returned in ESTALE (and not ENOENT). Even though ENOENT might<br>
> > look "proper" most of the time, as the application eventually expects<br>
> > ENOENT even if a parent directory does not exist, not returning<br>
> > ESTALE results in resolvers (FUSE and GFAPI) to not retry resolution<br>
> > in uncached mode. This can result in spurious ENOENTs during<br>
> > concurrent path modification operations.<br>
> ><br>
> > Change-Id: I7a06ea6d6a191739f2e9c6e333a1969615e05936<br>
> > BUG: 1032894<br>
> > Signed-off-by: Anand Avati <<a href="mailto:avati@redhat.com">avati@redhat.com</a>><br>
> > Reviewed-on: <a href="http://review.gluster.org/6322" target="_blank">http://review.gluster.org/6322</a><br>
> > Tested-by: Gluster Build System <<a href="mailto:jenkins@build.gluster.com">jenkins@build.gluster.com</a>><br>
> ><br>
> > Affected branches: master, 3.5, 3.4,<br>
> ><br>
> > Will be working with Venkatesh to get a fix for this on all these branches.<br>
> > Good catch venkatesh!!. Thanks a lot for a simple case to re-create the<br>
> > issue :-).<br>
><br>
> Thanks for the analysis, Pranith & Venkatesh! Let us make sure that we<br>
> add this test case to our regression tests.<br>
><br>
> ><br>
> > Vijay,<br>
> > Do you think we need this patch for 3.4 as well? Did we get enough<br>
> > baking time? The change seems delicate. In the sense that all the<br>
> > places which are expecting ENOENT need to be carefully examined.<br>
> > Even if we miss one place, we have a potential bug.<br>
><br>
><br>
> We would need to fix this in 3.4 failing which we will end up with a<br>
> regression from 3.4.1. For 3.4.2, we have two options:<br>
><br>
> 1. Revert the original commit<br>
><br>
> 2. Fix this problem<br>
<br>
</div></div>If we fix this problem, we will only be fixing this particular problem. We<br>
don't know if there are more similar issues. That is the reason I am a bit<br>
concerned about the nature of change introduced by the original commit.<br>
<span class="HOEnZb"><font color="#888888"><br>
Pranith<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
><br>
> I think we can reach a decision after you post a fix. We can base our<br>
> decision on the complexity/intrusiveness of the new patch.<br>
><br>
> -Vijay<br>
><br>
><br>
><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>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br><div dir="ltr"><i style="font-family:arial;font-size:small">Religious confuse piety with mere ritual, the virtuous confuse regulation with outcomes</i><br>
</div>
</div>