avati at gluster.com
Tue Aug 11 20:12:40 UTC 2009
> Okay, I believe I understand your reasoning, but this
> would not appear to alleviate my problem of trying to
> access a directory that is not seen as related to the
> call of the parent xlator/brick.
> i.e. parent xlator;
> write(/x/y/target.txt, data)
> my xlator;
> alter that data, making notes
> write(/x/y/target.txt, altered)
> write(/a/b/c/file.txt, notes)
> Meaning that I can readily retrieve context for
> the /x/y and /x/y/target.txt relationship, but not
> for the /a/b/c and /a/b/c/file.txt relationship.
if /a/b/c and /x/y are on the same "mountpoint", you have to use the itable got from an inode in the write(/x/y/target.txt) call (fd->inode->table). Using this itable you use the inode_from_path() api, and lookup/mkdir the /a/b prefixes depending on whether you find them or not. you might find the code to do this a bit voluminous because of the asynchronous nature of things, but this also come with a lot of flexibility and power.
> This makes sense for almost every case; I don't
> understand the path-translator - how does it
> avoid the need to play with the inode tables of
> the parent/child to achieve its outcome?
> Maybe it didn't .. hmm .. ok ... That aside;
> > There is a reason why just a few @this have itable while
> others do
> > not. On the client side, only the fuse's @this has a
> proper itable
> > initialized at mount time. On the server side, each
> subvolume of
> > protcol/server has a different itable of its own. Since
> two posix
> > exports from a single backend cannot share the same
> itable, each of
> > their itable is stored in their respective @this
> structures. And this
> > itable is initialized only when the first client attaches
> to this as
> > its remote-subvolume (i.e, during the setvolume MOP, which
> is the
> > handshake + authentication).
> ... am I right to believe that if I set up my own
> mop->subvolume that I would then be gifted with a
> populated itable?
no, you dont need to implement anything related to setvolume.. just pick the inode tables coming in from fops via loc->inode->table or fd->inode->table. dont look for a 'generally accessible inode table', just stick with the ones which come with fops.
> Would that be the appropriate way for me to obtain
> a populated itable, even in the case where my xlator
> is not an immediate child of the server xlator?
As I said, that is a wrong question if it is asked outside the scope of an fop. A translator should not have such an associated inode table with it. The reason itable is placed in the @this structure is so that it makes the life of protocol/server's life easy to get the right itable associated with a remote-subvolume. Protocol/server fills up the loc_t and initiates the fops. rest of the translators (including your translator which might happen to be the remote-subvolume) just use loc_t->inode->table and dont look at @this->itable directly ever.
More information about the Gluster-devel