Re: [Qemu-devel] [PATCH v6 2/2] block: Support GlusterFS as a QEMU block backend

[Kevin Wolf <kwolf@redhat.com>]

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