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

[Anand Avati]

>   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