Re: [Gluster-devel] RFC/Review: libgfapi object handle based extensions

[Anand Avati]

> 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