[Gluster-devel] upstream: Symbolic link not getting healed

[Harshavardhana]

GFAPI observes ENOENT with glfs_stat() - so the fix is necessary.


On Wed, Dec 18, 2013 at 9:55 PM, Pranith Kumar Karampuri <
pkarampu at redhat.com> wrote:

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



-- 
*Religious confuse piety with mere ritual, the virtuous confuse regulation
with outcomes*
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://supercolony.gluster.org/pipermail/gluster-devel/attachments/20131219/d016d9ad/attachment-0001.html>