avati at gluster.com
Tue Aug 11 20:24:19 UTC 2009
> In the write fop, I have an fd. That fd->inode->table does
> exist (is not null) but does not contain references to
> 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.
More information about the Gluster-devel