[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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://supercolony.gluster.org/pipermail/gluster-devel/attachments/20130930/6ddf2697/attachment.html>