> 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
