|
From: | Anand Avati |
Subject: | Re: [Gluster-devel] RFC/Review: libgfapi object handle based extensions |
Date: | Mon, 30 Sep 2013 19:16:59 -0700 |
> Now consider what happens in case of READDIRPLUS. A list of names and handlesI 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.
> 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.
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.
> 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.
[Prev in Thread] | Current Thread | [Next in Thread] |