<div dir="ltr"><br><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">
> Now consider what happens in case of READDIRPLUS. A list of names and handles<br>
> are returned to the client. The list of names can possibly include names<br>
> which were previously looked up as well. Both are supposed to represent the<br>
> same "gfid", but here will be returning new glfs_objects. When a client<br>
> performs an operation on a GFID, on which glfs_object will the operation be<br>
> performed at the gfapi layer? This part seems very ambiguous and not clear.<br>
<br>
</div>I should have made a note for readdirplus earlier, this would default to the fd based version of the same, not a handle/object based version of the same. So we would transition from an handle to an fd via glfs_h_opendir and then continue with the readdir variants. if I look at the POSIX *at routines, this seem about right, but of course we may have variances here.<br>
</blockquote><div><br></div><div>You would get an fd for the directory on which the READDIRPLUS is attempted. I was referring to the replies, where every entry needs to be returned with its own handle (on which operations can arrive without LOOKUP). Think of READDIRPLUS as bulk LOOKUP.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im"><br>
> What would really help is if you can tell what a glfs_object is supposed to<br>
> represent? - an on disk inode (i.e GFID)? an in memory per-graph inode (i.e<br>
> inode_t)? A dentry? A per-operation handle to an on disk inode? A<br>
> per-operation handle to an in memory per-graph inode? A per operation handle<br>
> to a dentry? In the current form, it does not seem to fit any of the these<br>
> categories.<br>
<br>
</div>Well I think of it as a handle to an file system object. Having said that, if we just returned the inode pointer as this handle, the graph switches can cause a problem, in which case we need to default to the (as per my understanding) the FUSE manner of working. keeping the handle 1:1 via other infrastructure does not seem beneficial ATM. I think you cover this in the subsequent mail so let us continue there.<br>
</blockquote><div><br></div><div>That is correct, using inode_t will force us to behave like FUSE. As mentioned in the other mail, we are probably better off fixing that and using inode_t in a cleaner way in both FUSE and gfapi.</div>
<div><br></div><div>Avati</div></div></div></div>