<div>Hello,</div><div><br></div><div>   I wasn&#39;t using the synctask_new worker, but now I implemented my code using it to trigger the create/write call. Btw, is the usage of syncop calls documented somewhere? I found it through the history of the dev-list.<div>

<br></div><div>  But going ahead on my issue, I was able to create the file avoiding the NFS stale handle error. The file is being created at the backend, but the syncop_create call it&#39;s still returning an error from the posix translator at the server side. I copied the error from the glusterd log below... I am checking the code trying to figure it out.</div>

<div><br></div><div>  To write the file I am generating a new gfid for the local file and setting the pargfid as 1 (root node) with the loc.parent pointing to the inode-&gt;table-&gt;root inode. Below I copied what is being copied the loc, fd, flag and mode_t structures being used at the create call. </div>

<div><br></div><div>*** From the glusterd log:</div><div><div>[2012-09-10 18:12:34.035940] W [posix-handle.c:590:posix_handle_hard] 0-examplevol1: mismatching ino/dev between file /bricks/exampleDir_local/1ccfca9f (146628/2049) and handle /bricks/exampleDir_local/.glusterfs/00/00/00000000-0000-0000-0000-000000000000 (146617/2049)</div>

<div>[2012-09-10 18:12:34.035977] E [posix.c:1724:posix_create] 0-examplevol1: setting gfid on /bricks/exampleDir_local/1ccfca9f failed</div></div><div><br></div>*** Relevant code before calling the create function</div>
<div>
<div> 107                 inode_t *newinode = inode_new (old_loc.inode-&gt;table);</div><div> 108 </div><div> 109                 loc.path = strdup(hashed_path_str);</div><div> 110                 <a href="http://loc.name">loc.name</a> = strdup(hashed_filename_str);</div>

<div> 111                 loc.inode = newinode;</div><div> 113                 loc.parent = loc.inode-&gt;table-&gt;root;</div><div> 115                 uuid_copy(loc.gfid, gfid);</div><div> 116 </div><div> 118                 memset (loc.pargfid, 0, 16);</div>

<div> 119                 loc.pargfid[15] = 1;</div><div> 120 </div><div> 121                 fd = fd_create (loc.inode, getpid());</div><div>...</div><div> 127 </div><div> 128                 uint32_t flags = O_CREAT | O_RDWR | O_EXCL;</div>

<div> 129                 mode_t mode = (mode_t)0700;</div><div> 130                 fd-&gt;flags = flags;</div><div> 131                 fd = fd_ref(fd);</div><div><br></div><div><br></div>Gustavo Bervian Brand<br>---------------------------------------------------------------------------------<br>


<br><br><div class="gmail_quote">On Sun, Sep 9, 2012 at 8:10 PM, Anand Avati <span dir="ltr">&lt;<a href="mailto:anand.avati@gmail.com" target="_blank">anand.avati@gmail.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<br><br><div class="gmail_quote"><div class="im">On Sun, Sep 9, 2012 at 11:09 AM, Anand Avati <span dir="ltr">&lt;<a href="mailto:anand.avati@gmail.com" target="_blank">anand.avati@gmail.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">


<br><br><div class="gmail_quote"><div><div>On Sun, Sep 9, 2012 at 10:53 AM, Gustavo Bervian Brand <span dir="ltr">&lt;<a href="mailto:gugabrand@gmail.com" target="_blank">gugabrand@gmail.com</a>&gt;</span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hello,<div><br></div><div>  I&#39;m implementing a translator and at the moment I&#39;m trying to &quot;cache&quot; at the local node&#39;s disk the files read from other node. </div><div>  When reading a file from a certain node, at the file open function it&#39;s added an extended metadata at the original file with info about where this file (or part of it) is copied, calling syncop_setxattr to the proper child to do it.</div>






<div>  So, once open is done the readv comes and if this file was not already read/cached, at the readv_cbk (before stack unwind) I am trying to create a local file with the content got from the original node.</div><div>





<br>
</div><div>  For that purpose, I am using syncop_create / setattr / write. But the syncop_create is always failing with Stale NFS file handle error.</div><div>  I tried to copy the same gfid and pargfid of the loc_t used at open function (saved), it didn&#39;t work, tried to zero them, nothing... and manipulated all the variables used at the syncop_create call... but nothing worked to get a success return from syncop_create.</div>






<div><br></div><div>  Is there some requirement to call syncop_create, or a good way to track the exact reason for this failure (I could see it&#39;s not even reaching the client_create() call through gdb)? I am using the code from the master branch of 1 week ago. Any comment is welcome. </div>


</blockquote></div></div></div></blockquote><div><br></div></div><div>And BTW, I hope you are performing the syncop_XXXX() calls inside a synctask_new() worker?</div><span class="HOEnZb"><font color="#888888"><div><br></div>

<div>Avati</div></font></span><div class="im"><div><br></div><div><br></div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="gmail_quote"><div><div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">






<div><br></div><div><br></div><div>Part of the log:</div><div><br></div><div><div>[2012-09-09 17:04:16.357875] I [gbfs_t.c:361:gbfs_open_cbk] 0-gbfs-test: entering gbfs_open_cbk function</div><div>[2012-09-09 17:04:16.358026] I [gbfs_t.c:169:gbfs_readv] 0-gbfs-test: entering gbfs_readv function</div>






<div>[2012-09-09 17:04:16.358156] I [gbfs_t.c:46:gbfs_readv_cbk] 0-gbfs-test: entering gbfs_readv_cbk function</div><div>[2012-09-09 17:04:16.358192] I [gbfs_t.c:132:gbfs_readv_cbk] 0-gbfs-test: failed to create /35a710dd on examplevol-client-0 (Stale NFS file handle)</div>






<div><br></div></div></blockquote><div><br></div></div></div><div>It will be good to put a break-point at gbfs_readv_cbk to inspect the backtrace to find which layer did the STACK_UNWIND(..,ESTALE...); and continue debugging from there.</div>



<div><br></div><div>For a create, you are expected to:</div><div>- fill loc.pargfid</div><div>- fill loc.basename</div><div>- fill loc.inode (obtained via inode_new())</div><div>- fill &quot;gfid-req&quot; key in xdata dictionary with a GFID to be assigned for the newly created file.</div>



<div><br></div><div>You can inspect posix_create() and client_create() to double check what the &quot;dependencies&quot; are. Note that if what you are creating is just a cached version of the original file, then it might be a good idea to re-use its gfid too.</div>


<span><font color="#888888">
<div><br></div><div>Avati</div><div><br></div></font></span></div>
</blockquote></div></div><br>
</blockquote></div><br></div>