[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PATCH v6 2/2] block: Support GlusterFS as a QEMU block
From: |
Kevin Wolf |
Subject: |
Re: [Qemu-devel] [PATCH v6 2/2] block: Support GlusterFS as a QEMU block backend |
Date: |
Tue, 14 Aug 2012 11:58:24 +0200 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:13.0) Gecko/20120605 Thunderbird/13.0 |
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
Re: [Qemu-devel] [PATCH v6 0/2] GlusterFS support in QEMU - v6, Bharata B Rao, 2012/08/13