From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:48650) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1T1DtR-0006Ej-3a for qemu-devel@nongnu.org; Tue, 14 Aug 2012 05:58:35 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1T1DtP-0001pS-W4 for qemu-devel@nongnu.org; Tue, 14 Aug 2012 05:58:33 -0400 Received: from mx1.redhat.com ([209.132.183.28]:21406) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1T1DtP-0001pL-OH for qemu-devel@nongnu.org; Tue, 14 Aug 2012 05:58:31 -0400 Message-ID: <502A2140.9050703@redhat.com> Date: Tue, 14 Aug 2012 11:58:24 +0200 From: Kevin Wolf MIME-Version: 1.0 References: <20120809130010.GA7960@in.ibm.com> <20120809130216.GC7960@in.ibm.com> <5028F815.40309@redhat.com> <20120814043801.GB24944@in.ibm.com> <502A0C66.3060107@redhat.com> <20120814093430.GE24944@in.ibm.com> In-Reply-To: <20120814093430.GE24944@in.ibm.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH v6 2/2] block: Support GlusterFS as a QEMU block backend List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: bharata@linux.vnet.ibm.com Cc: Anthony Liguori , Anand Avati , Stefan Hajnoczi , Vijay Bellur , Amar Tumballi , qemu-devel@nongnu.org, Blue Swirl , Paolo Bonzini 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