Re: FIRST_CHILD(frame->this)->fops->create

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

 



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/




[Index of Archives]     [Gluster Users]     [Ceph Users]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux]     [Linux OMAP]     [Linux MIPS]     [eCos]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux