nfs-ganesha get_gsh_client receives ss_family as 0 rather than AF_VSOCK |
|||||
Issue descriptionnfs-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.
,
Jul 11 2017
,
Sep 7 2017
slavamn, can we close this since we're not using vsock?
,
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
,
Sep 11 2017
,
May 9 2018
|
|||||
►
Sign in to add a comment |
|||||
Comment 1 by chirantan@chromium.org
, Jul 8 2017