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

[Ian Latter]

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 at gluster.com>
>To: "Ian Latter" <ian.latter at midnightcode.org>
>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/