> > 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
