On Wed, Dec 18, 2013 at 9:55 PM, Pranith Kumar Karampuri
<address@hidden <mailto:address@hidden>> wrote:
----- Original Message -----
> From: "Vijay Bellur" <address@hidden <mailto:address@hidden>>
> To: "Pranith Kumar Karampuri" <address@hidden
<mailto:address@hidden>>, "Venkatesh Somyajulu"
<address@hidden <mailto:address@hidden>>
> Cc: address@hidden <mailto:address@hidden>
> 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 <address@hidden <mailto:address@hidden>>
> > 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 <address@hidden
<mailto:address@hidden>>
> > Reviewed-on: http://review.gluster.org/6322
> > Tested-by: Gluster Build System <address@hidden
<mailto:address@hidden>>
> >
> > 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
address@hidden <mailto:address@hidden>
https://lists.nongnu.org/mailman/listinfo/gluster-devel
--
/Religious confuse piety with mere ritual, the virtuous confuse
regulation with outcomes/