Am 14.08.2012 11:34, schrieb Bharata B Rao: > On Tue, Aug 14, 2012 at 10:29:26AM +0200, Kevin Wolf wrote: >>> >>> Yes, and that will result in port=0, which is default. So this is to >>> cater for cases like gluster://[1:2:3:4:5]:/volname/image >> >> So you consider this a valid URL? I would have expected it to invalid. >> But let me see, there must be some official definition of an URL... >> >> Alright, so RFC 2234 says that having no digits after the colon is >> valid. It also says that you shouldn't generate such URLs. And it >> doesn't say what it means when it's there... Common interpretation seems >> to be that it's treated as if it wasn't specified, i.e. the default port >> for the schema is used. >> >> So if 0 is the default port for glusterfs, your code looks okay. But it >> doesn't seem to be a very useful default port number. > > I know, but gluster prefers to be called with port=0 which will be interpreted > as "default" by it.
Ok, that makes sense. > While we are at this, let me bring out another issue. Gluster supports 3 > transport types: > > - socket in which case the server will be hostname, ipv4 or ipv4 address. > - rdma in which case server will be interpreted similar to socket. > - unix in which case server will be a path to unix domain socket and this > will look like any other filesystem path. (Eg. /tmp/glusterd.socket) > > I don't think we can fit 'unix' within the standard URI scheme (RFC 3986) > easily, but I am planning to specify the 'unix' transport as below: > > gluster://[/path/to/unix/domain/socket]/volname/image?transport=unix > > i,e., I am asking the user to put the unix domain socket path within > square brackets when transport type is unix. > > Do you think this is fine ? Never saw something like this before, but it does seem reasonable to me. Excludes ] from the valid characters in the file name of the socket, but that shouldn't be a problem in practice. >>>>> +static int qemu_gluster_send_pipe(BDRVGlusterState *s, GlusterAIOCB *acb) >>>>> +{ >>>>> + int ret = 0; >>>>> + while (1) { >>>>> + fd_set wfd; >>>>> + int fd = s->fds[GLUSTER_FD_WRITE]; >>>>> + >>>>> + ret = write(fd, (void *)&acb, sizeof(acb)); >>>>> + if (ret >= 0) { >>>>> + break; >>>>> + } >>>>> + if (errno == EINTR) { >>>>> + continue; >>>>> + } >>>>> + if (errno != EAGAIN) { >>>>> + break; >>>>> + } >>>>> + >>>>> + FD_ZERO(&wfd); >>>>> + FD_SET(fd, &wfd); >>>>> + do { >>>>> + ret = select(fd + 1, NULL, &wfd, NULL, NULL); >>>>> + } while (ret < 0 && errno == EINTR); >>>> >>>> What's the idea behind this? While we're hanging in this loop noone will >>>> read anything from the pipe, so it's unlikely that it magically becomes >>>> ready. >>> >>> I write to the pipe and wait for the reader to read it. The reader >>> (qemu_gluster_aio_event_reader) is already waiting on the other end of the >>> pipe. >> >> qemu_gluster_aio_even_reader() isn't called while we're looping here. It >> will only be called from the main loop, after this function has returned. > > May be I am not understanding you correctly here. Let me be a bit verbose. > [...] Sorry, my mistake. I was assuming that this code runs in a thread created by qemu, which isn't true. Your explanation makes perfect sense. Kevin