qemu-devel
[Top][All Lists]
Advanced

[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: Avi Kivity
Subject: Re: [Qemu-devel] [PATCH v6 2/2] block: Support GlusterFS as a QEMU block backend
Date: Thu, 06 Sep 2012 11:29:36 +0300
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:14.0) Gecko/20120717 Thunderbird/14.0

On 08/14/2012 12:58 PM, Kevin Wolf wrote:
> 
>> 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.

Bikeshedding, but I prefer

  gluster:///path/to/unix/domain/socket:/volname/image?transport=unix

as being more similar to file://, or even

  gluster:///path/to/unix/domain/socket/volname/image?transport=unix

with the last two components implied to be part of the payload, not the
path.

-- 
error compiling committee.c: too many arguments to function



reply via email to

[Prev in Thread] Current Thread [Next in Thread]