> > Now consider what happens in case of READDIRPLUS. A list of names and > handles > > are returned to the client. The list of names can possibly include names > > which were previously looked up as well. Both are supposed to represent > the > > same "gfid", but here will be returning new glfs_objects. When a client > > performs an operation on a GFID, on which glfs_object will the operation > be > > performed at the gfapi layer? This part seems very ambiguous and not > clear. > > 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. >
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. > > > What would really help is if you can tell what a glfs_object is supposed > to > > represent? - an on disk inode (i.e GFID)? an in memory per-graph inode > (i.e > > inode_t)? A dentry? A per-operation handle to an on disk inode? A > > per-operation handle to an in memory per-graph inode? A per operation > handle > > to a dentry? In the current form, it does not seem to fit any of the > these > > categories. > > 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. > 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. Avati
_______________________________________________ Gluster-devel mailing list Gluster-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/gluster-devel