gluster-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Anand Avati
Subject: Re: [Gluster-devel] FIRST_CHILD(frame->this)->fops->create
Date: Tue, 11 Aug 2009 15:24:19 -0500 (CDT)

>   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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]