----- Original Message ----- > From: "Pranith Kumar Karampuri" <pkara...@redhat.com> > To: "Emmanuel Dreyfus" <m...@netbsd.org> > Cc: gluster-devel@nongnu.org > Sent: Thursday, December 26, 2013 11:28:59 AM > Subject: Re: [Gluster-devel] 3.5.1qa4 performances > > Emmanuel, > When files are created and deleted even before self-heal completes, > stale index files will be left in .glusterfs/indices/xattrop directory. > Self-heal-daemon is supposed to delete these stale indices. > Self-heal-daemon figures out that these indices are stale by checking > if the op_errno on the lookup is ENOENT. But now it could return ESTALE > with the following patch. So the stale index file remains and lookups > keep on happening forever. > > This is the patch which introduced the change in behavior: > > commit d1879d04e39258ea25a49eed3244b395d4af2c1d > Author: Anand Avati <av...@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.
Sent the fix for both master and 3.5 http://review.gluster.com/6593 http://review.gluster.com/6592 Pranith > > Pranith > ----- Original Message ----- > > From: "Emmanuel Dreyfus" <m...@netbsd.org> > > To: "Pranith Kumar Karampuri" <pkara...@redhat.com> > > Cc: gluster-devel@nongnu.org > > Sent: Thursday, December 26, 2013 11:22:45 AM > > Subject: Re: [Gluster-devel] 3.5.1qa4 performances > > > > Emmanuel Dreyfus <m...@netbsd.org> wrote: > > > > > I search .glusterfs/cf/1b/cf1bdf4f-b71c-4fda-963d-b7e4547e1b7c on each > > > bricks: it does not exist anywhere. I tried with other "Stale NFS file > > > handle" messages, and the file never exists in glusterfs index tree. > > > > I suspect it has something to do with that warning on client log, which > > happens > > once: > > > > [2013-12-25 06:04:00.111064] W > > [client-rpc-fops.c:1744:client3_3_xattrop_cbk] > > 0-gfs351-client-0: remote operation failed: Undefined error: 0. Path: > > /manu/usr/src/games/backgammon/common_source/obj/one.o > > (cf1bdf4f-b71c-4fda-963d-b7e4547e1b7c) > > > > Althought the index does not exist, the file does: > > silo:/export/wd2a//manu/usr/src/games/backgammon/common_source/obj/one.o > > hangar:/export/wd1a//manu/usr/src/games/backgammon/common_source/obj/one.o > > > > Both have same extended attributes: > > > > trusted.afr.gfs351-client-0 > > 000 00 00 00 00 00 00 00 00 00 00 00 00 ............ > > trusted.afr.gfs351-client-1 > > 000 00 00 00 00 00 00 00 00 00 00 00 00 ............ > > trusted.afr.gfs351-gfid > > 000 da 17 69 27 49 8f 4d e6 99 2b 53 25 be 9d 11 a3 > > ..i'I.M..+S%.... > > > > For parent directory, trusted.gfid is the same on all bricks. > > trusted.glusterfs.dht it: > > silo:/export/wd2a//manu/usr/src/games/backgammon/common_source/obj > > 000 00 00 00 01 00 00 00 00 00 00 00 00 7f ff ff fe ............... > > hangar:/export/wd1a//manu/usr/src/games/backgammon/common_source/obj > > 000 00 00 00 01 00 00 00 00 00 00 00 00 7f ff ff fe ............... > > hangar:/export/wd3a//manu/usr/src/games/backgammon/common_source/obj > > 000 00 00 00 01 00 00 00 00 7f ff ff ff ff ff ff ff ............... > > debacle:/export/wd1a//manu/usr/src/games/backgammon/common_source/obj > > 000 00 00 00 01 00 00 00 00 7f ff ff ff ff ff ff ff ............... > > > > -- > > Emmanuel Dreyfus > > http://hcpnet.free.fr/pubz > > m...@netbsd.org > > > _______________________________________________ Gluster-devel mailing list Gluster-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/gluster-devel
