New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 740289 link

Starred by 3 users

Issue metadata

Status: WontFix
Owner:
Last visit > 30 days ago
Closed: Sep 2017
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Chrome
Pri: 3
Type: Bug



Sign in to add a comment

nfs-ganesha get_gsh_client receives ss_family as 0 rather than AF_VSOCK

Project Member Reported by abiusx@google.com, Jul 8 2017

Issue description

nfs-ganesha's support/client_mgr.c:get_gsh_client():165 (augmented with vsock per https://chromium-review.googlesource.com/c/563719/) receives sockaddr_t which has a ss_family == 0 rather than ss_family == AF_VSOCK.

It triggers the assert(0) put there to catch errors, and core dumps. 
 
Can you post the stack trace?  Looking at the code there are a couple of places where the address could come from and at least one of them doesn't actually set the .sa_family field.


Project Member

Comment 2 by sheriffbot@chromium.org, Jul 11 2017

Labels: Hotlist-Google
Owner: slavamn@chromium.org
slavamn, can we close this since we're not using vsock?

Comment 4 by slavamn@google.com, Sep 9 2017

Indeed, we should close this as won't fix. Quoting analysis I sent to the group earlier:

In my experiments, NFS4 over vsock wasn't reliable: 1 out of 2 kernel compile runs crashed with it. The NFS over IP always succeeded.

The vsock version also currently uses vsock-to-IP bridge (nc-vsock) that affects performance. I tried to estimate the performance impact by running NFSv4 with port 2050, and using ssh, pair of netcat processes or socat to simulate the effect of vsock/IP bridge. Unfortunately, the port forwarding with IP has very high cost, so I wasn't able to approximate the nc-vsock overhead.

At any rates, NFS4/IP is 1.62x faster than NFS4/vsock, and NFS3/IP is 2.5x faster. Given immaturity of vsock backend, effort required to finish and stabilize it, and lack of performance benefits, I think we should focus on NFSv3/IP.

=== Appendix

Detailed time:
    Host kernel 3.14
        crosvm
            tmpfs -j4 and -j5: 5.25
            nfs4 -j4: 22.59, 22.59
            nfs3, nolock -j4: 9:43, 9:42
        lkvm
            nfs3, nolock, -j4: 9:11, 9:13
            tmpfs -j4: 5:30, 5:32
    Host kernel 4.4
        lkvm
            # nfs4 default is TCP
            tmpfs -j4: 5:30, 5:32
            nfs4, nc-vsock -j4: 23:12
            nfs4, *no* nc -j4: 14:48
            nfs3, nolock, *no* nc -j4: 9:18
            nfs4, 2 nc processes -j4: 35:47
            nfs4, ssh forwarding -j4: 59:23
            nfs4, socat,fork forwarding -j4: 35:32

All experiments were done using dgreid@'s dev_container.img by running following snippet in Guest. Notice I am running with -j4 instead of -j5, as -j4 was more sensitive to I/O performance in my prior experiments:

   mkdir /tmp/container
   mount /dev/vdb /tmp/container
   # one of mount lines below
   chroot /tmp/container/rootfs
   export PATH=${PATH}:/usr/lib/x86_64-linux-gnu/5/
   cd /tmp
   tar xf /linux-4.12.5.tar.xz
   cd linux-4.12.5
   make defconfig
   time make -j4

NFS command line on the Host for all experiments:

    /usr/bin/ganesha.nfsd -F -NNIV_NULL -L/dev/stderr -f /tmp/ganesha.conf

Mount line for NFSv3/IP mount in the Guest (no port forwarding):

   mount -vvv -o nolock,vers=3 100.115.92.1:/tmp/exports /tmp/container/rootfs/tmp

Mount line for NFSv4/IP mount in the Guest (no port forwarding - it defaults to tcp protocol):

   mount -vvv -o vers=4 100.115.92.1:/user /tmp/container/rootfs/tmp

Mount line for NFSv4/vsock mount in the Guest:

   mount -vvv -o vers=4,proto=vsock 12:/user /tmp/container/rootfs/tmp

Mount line for NFSv4/IP with port forwarding, using one of the Host port forwarding methods mentioned below:

   mount -vvv -o vers=4,proto=tcp,port=2050,mountport=2050 100.115.92.1:/user /tmp/container/rootfs/tmp

Port forwarding on Host using socat:

   ./socat TCP4-LISTEN:2050,fork TCP4:127.0.0.1:2049

Port forwarding on Host using ssh:

   ssh -L 100.115.92.1:2050:127.0.0.1:2049 chronos@127.0.0.1

Port forwarding on Host using nc (while-done because nc quits when session is closed):

   mkfifo backpipe
   while true; do ./nc -kl 100.115.92.1 2050 0<backpipe | ./nc 127.0.0.1 2049 1>backpipe; done
Status: WontFix (was: Untriaged)
Components: OS>Systems>Containers

Sign in to add a comment