gluster-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Anand Avati
Subject: Re: [Gluster-devel] FIRST_CHILD(frame->this)->fops->create
Date: Tue, 11 Aug 2009 15:12:40 -0500 (CDT)

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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]