Re: [Gluster-devel] bug 851381

[Pranith Kumar Karampuri]

hi Jules Wang,
   I believe this code is from client xlator. Multiple mounts can operate on 
the same volume. Lets say mount1 did a lookup and found that the gfid of the 
file 'a' is 'g1' now another mount 'mount2' could delete and create another 
file with same name 'a' with gfid 'g2'. Now when mount1 does lookup for 
revalidation the file is not same any more. So it sends -1, ESTALE as op_ret, 
op_errno respectively. Fuse will do a fresh lookup again to figure out inode 
info of the new file. The reason client xlator does not take the decision to 
modify gfids is because it is not a global xlator, it only knows about 1 brick. 
Fuse/nfs are global xlators. They are responsible for maintaining the global 
namespace in all possible configurations like afr, dht, stripe and their 
combinations.

Please let us know if you have any doubts.

Pranith.
----- Original Message -----
From: "Jules Wang" <address@hidden>
To: "devel" <address@hidden>
Sent: Thursday, September 20, 2012 9:22:33 AM
Subject: [Gluster-devel] bug 851381




hi, all 
When tracing bug 851381 ( https://bugzilla.redhat.com/show_bug.cgi?id=851381 
),, I found following code caused the problem: 


if ((!uuid_is_null (inode->gfid)) 
&& (uuid_compare (stbuf.ia_gfid, inode->gfid) != 0)) { 
gf_log (frame->this->name, GF_LOG_DEBUG, 
"gfid changed for %s", local->loc.path); 
rsp.op_ret = -1; 
op_errno = ESTALE; 
! goto out; 
} 


I could fix it by simply changing the code to "uuid_copy(inode->gfid, 
stbuf.ia_gfid);", but I think throw a error is the intended behavior. 
So, why we throw a error when gfid is changed? 


Best Regards. 
Jules Wang. 


_______________________________________________
Gluster-devel mailing list
address@hidden
https://lists.nongnu.org/mailman/listinfo/gluster-devel