Re: [Qemu-devel] [Qemu-block] block/nfs: Fine grained runtime options in nfs

[Ashijeet Acharya]

On Tue, Oct 18, 2016 at 9:43 PM, Ashijeet Acharya
<address@hidden> wrote:
> On Tue, Oct 18, 2016 at 7:03 PM, Kevin Wolf <address@hidden> wrote:
>> Am 18.10.2016 um 15:14 hat Ashijeet Acharya geschrieben:
>>> On Tue, Oct 18, 2016 at 6:34 PM, Kevin Wolf <address@hidden> wrote:
>>> > Am 18.10.2016 um 14:46 hat Ashijeet Acharya geschrieben:
>>> >> On Tue, Oct 18, 2016 at 4:11 PM, Peter Lieven <address@hidden> wrote:
>>> >> > Am 17.10.2016 um 21:34 schrieb Ashijeet Acharya:
>>> >> >>
>>> >> >> On Tue, Oct 18, 2016 at 12:59 AM, Eric Blake <address@hidden> wrote:
>>> >> >>>
>>> >> >>> On 10/17/2016 01:00 PM, Ashijeet Acharya wrote:
>>> >> >>>
>>> >> >>>> One more relatively easy question though, will we include @port as 
>>> >> >>>> an
>>> >> >>>> option in runtime_opts while converting NFS to use several
>>> >> >>>> runtime_opts? The reason I ask this because the uri syntax for NFS 
>>> >> >>>> in
>>> >> >>>> QEMU looks like this:
>>> >> >>>>
>>> >> >>>>
>>> >> >>>> nfs://<host>/<export>/<filename>[?param=value[&param2=value2[&...]]]
>>> >> >>>
>>> >> >>> It's actually nfs://<host>[:port]/...
>>> >> >>>
>>> >> >>> so the URI syntax already supports port.
>>> >> >>
>>> >> >> But the commit message which added support for NFS had the uri which I
>>> >> >> mentioned above and the code for NFS does not make use of 'port'
>>> >> >> anywhere either, which is why I am a bit confused.
>>> >> >
>>> >> >
>>> >> > Hi Aschijeet,
>>> >> >
>>> >> > don't worry there is no port number when connecting to an NFS server.
>>> >> > The portmapper always listens on port 111. So theoretically we could
>>> >> > specifiy a port in the URL but it is ignored.
>>> >>
>>> >> So that means I will be including 'port' in runtime_opts and then just
>>> >> ignoring any value that comes through it?
>>> >
>>> > No, if there is nothing to configure there, leave it out. Adding an
>>> > option that doesn't do anything is not very useful.
>>> >
>>> Okay, understood.
>>>
>>> So this is what my runtime_opts look like now:
>>>
>>> static QemuOptsList runtime_opts = {
>>>     .name = "nfs",
>>>     .head = QTAILQ_HEAD_INITIALIZER(runtime_opts.head),
>>>     .desc = {
>>>         {
>>>             .name = "host",
>>>             .type = QEMU_OPT_STRING,
>>>             .help = "Host to connect to",
>>>         },
>>>         {
>>>             .name = "export",
>>>             .type = QEMU_OPT_STRING,
>>>             .help = "Name of the NFS export to open",
>>>         },
>>>         {
>>>             .name = "path",
>>>             .type = QEMU_OPT_STRING,
>>>             .help = "Path of the image on the host",
>>>         },
>>
>> Does libnfs actually have separate export and path?
>>
>> If I understand correctly, we currently split the URL at the last / in
>> the string. So is export the part before that and path the part after
>> it?
>
> At the moment, I don't see any piece of code in NFS BLOCK DRIVER which
> does that to extract export from the URL. We actually do this at the
> moment:
>
>     strp = strrchr(uri->path, '/');
>
> which I think is just to extract the name of the file from the URL and
> has nothing to do with export.
> Although NBD and gluster seem to extract export from the URL like this:
>
>     p += strspn(p, "/");
>
> which actually splits the URL at the first appearance of "/", doesn't
> it? And then does after checking for p[0]:
>
>     qdict_put(options, "export", qstring_from_str(p));
>
> which puts the value of key export in qdict as the part of the URL
> which occurs after the first appearance of "/", right?
>
>>
>> If so, does this mean that you can't currently access an image file in a
>> subdirectory of an NFS mount and adding the explicit options will fix
>> this?
>
> I am not sure of that :-/
>
But either way I think I will have to drop export and was a silly
mistake to include it, since it is extracted from path one way or
another.

Ashijeet