[Top][All Lists]
[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
- [Gluster-devel] FIRST_CHILD(frame->this)->fops->create, Ian Latter, 2009/08/04
- Re: [Gluster-devel] FIRST_CHILD(frame->this)->fops->create, Ian Latter, 2009/08/06
- Re: [Gluster-devel] FIRST_CHILD(frame->this)->fops->create, Ian Latter, 2009/08/06
- Re: [Gluster-devel] FIRST_CHILD(frame->this)->fops->create, Ian Latter, 2009/08/07
- Re: [Gluster-devel] FIRST_CHILD(frame->this)->fops->create, Ian Latter, 2009/08/10
- Re: [Gluster-devel] FIRST_CHILD(frame->this)->fops->create, Anand Avati, 2009/08/11
- Re: [Gluster-devel] FIRST_CHILD(frame->this)->fops->create,
Anand Avati <=
- Re: [Gluster-devel] FIRST_CHILD(frame->this)->fops->create, Ian Latter, 2009/08/11