Hello Avati, Thanks to your help I have had some success - I can now child->fops->create my file in the volume's root directory. The code is along the lines of; my function; itable = (inode_table_t *)this->itable; // Skipping string code .. // The test case outcomes are; // data_path = "/" // data_name = "file.txt" // data_path_name = "/file.txt" // The production case outcomes are; // data_path = "/a/b/c/d" // data_name = "file.txt" // data_path_name = "/a/b/c/d/file.txt" data_loc.inode = inode_new(itable); data_loc.parent = inode_from_path(itable, data_path); data_loc.path = data_path_name; data_loc.name = data_name; fd = fd_create(data_loc.inode, frame->root->pid); flags = O_CREAT | O_RDWR | O_EXCL; mode = (mode_t)0700; fd->flags = flags; fd = fd_ref(fd); // not sure about this yet, haven't looked it up // STACK_WIND(child->fops->create) // With: &data_loc, flags, mode, fd init; this->itable = inode_table_new(0, this); I have a problem, however. My inode table looks to be a private/local inode table, which doesn't make sense. And per my expectation, if I try to child->create to a directory that is outside of the root directory (i.e. parent path = "/"), or that I didn't create in this session (i.e. killall glusterfsd; mkdir -p /gluster-test-mount/a/b/c/d"; glusterfsd;) the inode_from_path function fails to recover an inode for that parent path (because it isn't in my local table). I tried to get myself access to a "real" inode table, per the trace source, with the following in init; this->itable = FIRST_CHILD(this)->itable; However, that itable is null in my case (glusterfs-2.0.2, child brick is a single locks brick, on a single posix brick, running on Linux). The only xlator that looks like it may initialise a global inode table is the server xlater. In server-protocol.c there is a "mop_setvolume" that contains the following initialiser; if ((conn->bound_xl != NULL) && (ret >= 0) && (conn->bound_xl->itable == NULL)) { /* create inode table for this bound_xl, if one doesn't already exist */ lru_limit = INODE_LRU_LIMIT (frame->this); gf_log (trans->xl->name, GF_LOG_TRACE, "creating inode table with lru_limit=%"PRId32", " "xlator=%s", lru_limit, conn->bound_xl->name); conn->bound_xl->itable = inode_table_new (lru_limit, conn->bound_xl); } However, I'm not clear on what mops are for, or how they're used. I can see that a mop is a "Management OPeration", but what is setvolume intended to do? And when is it called? If this is an initalising routine, then why couldn't this code be in init? (and if it can, then what am I doing wrong with my current initialiser, which is the same one used in the fuse mount xlator's init function?) Thanks for any direction that you can provide. ----- Original Message ----- >From: "Ian Latter" <ian.latter@xxxxxxxxxxxxxxxx> >To: "Anand Avati" <avati@xxxxxxxxxxx> >Subject: Re: [Gluster-devel] FIRST_CHILD(frame->this)->fops->create >Date: Thu, 06 Aug 2009 15:07:50 +1000 > > > > Excellent - thanks Avati. > > This also, then, confirms that my fd_create() version was > failing because of the incorrectly populated loc structure. > > It also didn't occur to me that the server xlator would have > the type of sample code I could use for this ... I'm working > my way through server_create() now ... and server_loc_fill() > from server-helpers.c ... > > It looks like you've opened some good avenues here; if I > get stuck I'll post back. > > > Thanks for your help - I look forward to contributing to the > project. > > > > ----- Original Message ----- > >From: "Anand Avati" <avati@xxxxxxxxxxx> > >To: "Ian Latter" <ian.latter@xxxxxxxxxxxxxxxx> > >Subject: Re: [Gluster-devel] > FIRST_CHILD(frame->this)->fops->create > >Date: Wed, 05 Aug 2009 20:29:27 -0700 > > > > If this is the actual code below you have in your fop, > please look for > > the comments inline - > > > > > Example code for the "hang" case, from my prototype (inside > > > a function called from inside the xlator->write handler); > > > > > > � � � �loc_t data_loc; > > > � � � �char path[255]; > > > � � � �char name[255]; > > > � � � �char * data_path; > > > � � � �char * data_name; > > > � � � �int32_t flags; > > > � � � �mode_t mode; > > > � � � �fd_t * fd; > > > > > > � � � �memset(path, 0, sizeof(path)); > > > � � � �if(snprintf(path, sizeof(path) - 1, "/data.db") <= 0) > > > � � � � �return -1; > > > > > > � � � �memset(name, 0, sizeof(name)); > > > � � � �if(snprintf(name, sizeof(name) - 1, "data.db") <= 0) > > > � � � � �return -1; > > > > > > � � � �data_path = CALLOC(1, strlen(path) + 1); > > > � � � �ERR_ABORT(data_path); > > > � � � �memset(data_path, 0, sizeof(data_path)); > > > � � � �memcpy(data_path, path, strlen(path)); > > > > > > � � � �data_name = CALLOC(1, strlen(name) + 1); > > > � � � �ERR_ABORT(data_name); > > > � � � �memset(data_name, 0, sizeof(data_name)); > > > � � � �memcpy(data_name, name, strlen(name)); > > > > > > � � � �memset(&data_loc, 0, sizeof(data_loc)); > > > � � � �data_loc.inode = NULL; �// redundant > > > > you need to have the loc->inode and loc->parent members > filled in > > properly. See fuse-bridge.c and server-protocol.c on how > to generate > > create()able inodes and fds. To reach the parent inode of the > > directory where the file needs to be created, refer the > > fuse_loc_fill() or server_loc_fill() functions. > > > > > � � � �data_loc.path = data_path; > > > � � � �data_loc.name = data_name; > > > > > > � � � �flags = O_CREAT | O_RDWR | O_EXCL; > > > > > > � � � �mode = (mode_t)0700; > > > > > > � � � �memset(fd, 0, sizeof(fd_t)); > > > > > > � � � �STACK_WIND(frame, > > > � � � � � � � � � �xlator_func_writev_create_cbk, > > > � � � � � � � � � �FIRST_CHILD(frame->this), > > > � � � � � � � � � �FIRST_CHILD(frame->this)->fops->create, > > > � � � � � � � � � �&data_loc, flags, mode, &fd); > > > > the fd pointer should be pre-allocated with fd_create(). Refer > > fuse_create() and fuse_create_cbk() to figure out the > right things to > > do. If you can describe your requirements in more detail, > we can > > suggest a few tips and directions on how to proceed. > > > > > � � � �gf_log(this->name, GF_LOG_WARNING, "Hung above me"); > > > > Avati > > > > > -- > Ian Latter > Late night coder .. > http://midnightcode.org/ > > > _______________________________________________ > Gluster-devel mailing list > Gluster-devel@xxxxxxxxxx > http://lists.nongnu.org/mailman/listinfo/gluster-devel > -- Ian Latter Late night coder .. http://midnightcode.org/