<br><br><div class="gmail_quote">On Sun, Sep 9, 2012 at 10:53 AM, Gustavo Bervian Brand <span dir="ltr"><<a href="mailto:gugabrand@gmail.com" target="_blank">gugabrand@gmail.com</a>></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'm implementing a translator and at the moment I'm trying to "cache" at the local node's disk the files read from other node. </div><div> When reading a file from a certain node, at the file open function it'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'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'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>
<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>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 "gfid-req" 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 "dependencies" 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>
<div><br></div><div>Avati</div><div><br></div></div>