ian.latter at midnightcode.org
Tue Aug 11 22:44:34 UTC 2009
Between all of your email, but the last two
particularly, I believe that my code is already
at this point.
In addition to the code that I last supplied, I
added an inode table pointer to the top of my
fop->write (I know I don't need to cache it, but
this worked best with my current code);
this->itable = fd->inode->table;
The problem is that, as you say, this is a
pruned inode table (as specified by the owner
of that inode table, not me), so there is no
reference to directories that I wish to
manipulate after a glusterfsd restart for
> Using a combination of inode_search(),
> inode_from_path(), inode_path(), -subvol->lookup,
> subvol->mkdir you can "setup" your extra
> directory structures, new files in them etc.
This is a new lead - I'm not familiar with the lookup
call - I will research this, thanks.
For what its worth, I had no problem with
FIRST_CHILD(this)->fops->mkdir, it didn't seem
to be hung-up on the need for inode references,
though I added these after your help with the
----- Original Message -----
>From: "Anand Avati" <avati at gluster.com>
>To: "Ian Latter" <ian.latter at midnightcode.org>
>Subject: Re: [Gluster-devel]
>Date: Tue, 11 Aug 2009 15:24:19 -0500
> > In the write fop, I have an fd. That fd->inode->table
> > exist (is not null) but does not contain references to
> > directories
> > that I had previously created on that volume (prior to a
> > glusterfsd restart, for example). I am attempting to
> > contents of that inode table to see what it does contain
> > I'm out of time again this evening.
> The inode table is an cache of inodes/dentries which are
accessed/created recently. Old entries get pruned out of the
table using an LRU algorithm (tuned by lru_limit specified
> > One other quick test has shown that mop->setvolume is
> > not being called on my xlator. So there is no alternative
> > avenue there.
> Please refer to the other email I wrote a few mins ago
which might answer this question.
> > I guess the question is - Is this the best path for
> > to create/read/write/remove files in an autonomous
> > management function (i.e. event driven, but without user/
> > upper level control over the target file/path)? I am
> > this juncture because to create a file required a new inode
> > and inode data of the parent. Is there another way to
> > a file in GlusterFS? I.e. can I get into the context of the
> > child and then perform an open() call (as opposed to an
> > open fop)?
> The only thing you need is a pointer to the inode table.
Once you have that (you can cache that pointer in your
private data if you think necessary too), you can
access/create/delete arbitrary paths, files and directories.
You need to construct the right loc_t's, create
call_frame_t's and you are good to fire fops. You also need
to understand that the inode table is just a cache of
inodes, with only the root inode assured to be in it all the
time. Using a combination of inode_search(),
inode_from_path(), inode_path(), -subvol->lookup,
subvol->mkdir you can "setup" your extra directory
structures, new files in them etc. You can get some hints
about how to "put data in a path" starting with just the
inode table by looking up code in server/protocol. You can
also get hings about filling up loc_t's properly from
protocol/server as well (see the code of the fop you want to
fire and check how the members are filled in). I understand
there are a lot of plugs and knobs which can be overwhelming
initially.. but once you get the hang of it they should not
appear so complex any more.
Late night coder ..
More information about the Gluster-devel