[Gluster-devel] FIRST_CHILD(frame->this)->fops->create

[Anand Avati]

> 
> 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)
>          create/open(/a/b/c/file.txt)
>          write(/a/b/c/file.txt, notes)
>          close(/a/b/c/file.txt)
> 
> 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.

Avati