Thanks Avati,
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
example.
> 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
create.
----- Original Message -----
>From: "Anand Avati" <avati@xxxxxxxxxxx>
>To: "Ian Latter" <ian.latter@xxxxxxxxxxxxxxxx>
>Subject: Re: [Gluster-devel]
FIRST_CHILD(frame->this)->fops->create
>Date: Tue, 11 Aug 2009 15:24:19 -0500
>
>
> > In the write fop, I have an fd. That fd->inode->table
does
> > 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
dump all
> > contents of that inode table to see what it does contain
.. but
> > 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
to inode_table_new()).
>
>
> > 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
attempting
> > 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
only at
> > this juncture because to create a file required a new inode
> > and inode data of the parent. Is there another way to
create
> > 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.
>
>
> Thanks,
> Avati
>
--
Ian Latter
Late night coder ..
http://midnightcode.org/
