[Gluster-devel] What tranpsort type in glfs_set_volfile_server() exactly mean ?
Raghavendra Talur
rtalur at redhat.com
Mon Jul 18 13:29:56 UTC 2016
On Mon, Jul 18, 2016 at 4:35 PM, Raghavendra Talur <rtalur at redhat.com>
wrote:
>
>
> On Mon, Jul 18, 2016 at 4:10 PM, Prasanna Kalever <pkalever at redhat.com>
> wrote:
>
>> Hey Team,
>>
>>
>> My understanding is that @transport argumet in
>> glfs_set_volfile_server() is meant for specifying transport used in
>> fetching volfile server,
>>
>
> Yes, @transport arg here is transport to use for fetching volfile.
>
>
>> IIRC which currently supports tcp and unix only...
>>
> Yes, this is correct too.
>
>
>>
>> The doc here
>> https://github.com/gluster/glusterfs/blob/master/api/src/glfs.h
>> +166 shows the rdma as well, which is something I cannot digest.
>>
> This is doc written with assumption that rdma would work too.
>
>
>>
>>
>> Can someone correct me ?
>>
>> Have we ever supported volfile fetch over rdma ?
>>
>
> I think no. To test, you would have to set rdma as only transport option
> in glusterd.vol and see what happens in volfile fetch.
>
Rafi, Prasanna and I looked at the code and verified that volfile is
fetched over tcp in the above case.
Here is the complete scenario
1. option: unix, volfile is fetched over unix.
2. option:tcp, volfile is fetched over socket.
3. option:rdma, volfile is fetched over socket with no warning about no
support for rdma.
This gives an illusion to user that volfile is also fetched over rdma,
whereas we used tcp connection for it. I would recommend deprecating the
volfile-server-transport option's overloaded usecase of deciding IO
transport in 3.9 version of Gluster and having a different option name for
it.
Thanks,
Raghavendra Talur
>
>
> IMO, fetching volfile over rdma is an overkill and would not be required.
> RDMA should be kept only for IO operations.
>
> We should just remove it from the docs.
>
> Thanks,
> Raghavendra Talur
>
>
>>
>> Thanks,
>> --
>> Prasanna
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.gluster.org/pipermail/gluster-devel/attachments/20160718/6b0df958/attachment.html>
More information about the Gluster-devel
mailing list