kernel-packages team mailing list archive
-
kernel-packages team
-
Mailing list archive
-
Message #71404
[Bug 1327563] Re: Long delay when mounting NFS shares
To add a bit of debugging I did (using two VMs):
- There server side kernel version does not matter (tested trusty and utopic)
- A client with a 3.13 kernel will have the delay, while the 3.16 kernel is ok
Enabling NFS debugging on both clients (as root "echo 32767
>/proc/sys/sunrpc/nfs_debug") shows an interesting fact:
3.13 client:
7581.776148] NFS: nfs4_discover_server_trunking: testing 'lam-utopic6401'
7581.776154] NFS call setclientid auth=RPCSEC_GSS, 'Linux NFSv4.0 192.168.2.19
7596.776086] RPC: AUTH_GSS upcall timed out.
7596.776086] Please check user daemon is running.
7596.776110] NFS reply setclientid: -13
7596.776121] NFS call setclientid auth=RPCSEC_GSS, 'Linux NFSv4.0 192.168.2.19
7597.024109] NFS reply setclientid: -13
7597.024766] NFS call setclientid auth=UNIX, 'Linux NFSv4.0 192.168.2.192/192.
7597.025506] NFS reply setclientid: 0
7597.025512] NFS call setclientid_confirm auth=UNIX, (client ID fb69c653040000
7597.026068] NFS reply setclientid_confirm: 0
3.16 client:
2137.866775] NFS: nfs4_discover_server_trunking: testing 'lam-utopic6401'
2137.866783] NFS call setclientid auth=UNIX, 'Linux NFSv4.0 192.168.2.120/192.
2137.867420] NFS reply setclientid: 0
2137.867426] NFS call setclientid_confirm auth=UNIX, (client ID fb69c653050000
2137.867727] NFS reply setclientid_confirm: 0
So the newer kernel seems to skip the other authentication methods. And
of those two AUTH_GSS is causing the delay because it times out.
Unfortunately I did not spot any commits in between 3.13 and now that
would immediately sound like a good candidate for fixing this.
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1327563
Title:
Long delay when mounting NFS shares
Status in “linux” package in Ubuntu:
Confirmed
Bug description:
Summary:
After upgrading the kernel on Ubuntu 14.04 to 3.13.0-29-generic I
found that it can take a considerably longer amount of time to mount
NFS shares.
How to reproduce:
1. Install Ubuntu 14.04 on two machines. A minimal server install should be fine. One will act as a server, the other as a client.
2. Upgrade the kernel on the client machine to at least 3.13.0-27-generic.
3. Install the nfs-kernel-server package on the server.
4. Add a directory to /etc/exports and run service nfs-kernel-server start.
5. Install the nfs-common package on the client.
6. Attempt to mount the shared directory on the client.
Expected result:
The shared directory should be mounted on the client more or less
immediately.
Actual result:
The mount command hangs and eventually completes. In this test case it
takes 16 seconds consistently. On a production machine where the
problem was first discovered the time is considerably longer and
essentially makes it impossible to mount NFS shares.
Regression:
I have been able to reproduce the problem on clients running Linux
3.13.0-27-generic and later. The problem is not reproducible on
clients running Linux 3.13.0-24-generic. The problem is reproducible
no matter which kernel version is used on the server.
Tested client kernel versions:
Linux 3.13.0-29-generic #53-Ubuntu FAIL
Linux 3.13.0-27-generic #50-Ubuntu FAIL
Linux 3.13.0-24-generic #47-Ubuntu OK
Tested server kernel versions:
Linux 3.13.0-29-generic #53-Ubuntu OK
Linux 3.13.0-27-generic #50-Ubuntu OK
Linux 3.13.0-24-generic #47-Ubuntu OK
lsb_release -rd:
Description: Ubuntu 14.04 LTS
Release: 14.04
apt-cache policy linux-image-generic:
linux-image-generic:
Installed: (none)
Candidate: 3.13.0.29.35
Version table:
3.13.0.29.35 0
500 http://se.archive.ubuntu.com/ubuntu/ trusty-updates/main amd64 Packages
500 http://security.ubuntu.com/ubuntu/ trusty-security/main amd64 Packages
3.13.0.24.28 0
500 http://se.archive.ubuntu.com/ubuntu/ trusty/main amd64 Packages
ProblemType: Bug
DistroRelease: Ubuntu 14.04
Package: linux-image-3.13.0-29-generic 3.13.0-29.53
ProcVersionSignature: Ubuntu 3.13.0-29.53-generic 3.13.11.2
Uname: Linux 3.13.0-29-generic x86_64
AlsaDevices:
total 0
crw-rw---- 1 root audio 116, 1 Jun 7 16:26 seq
crw-rw---- 1 root audio 116, 33 Jun 7 16:26 timer
AplayDevices: Error: [Errno 2] No such file or directory: 'aplay'
ApportVersion: 2.14.1-0ubuntu3.2
Architecture: amd64
ArecordDevices: Error: [Errno 2] No such file or directory: 'arecord'
AudioDevicesInUse: Error: [Errno 2] No such file or directory: 'fuser'
CRDA: Error: [Errno 2] No such file or directory: 'iw'
Date: Sat Jun 7 16:30:02 2014
HibernationDevice: RESUME=UUID=9c13108b-d40a-4881-b563-c477ed2e6804
InstallationDate: Installed on 2014-06-07 (0 days ago)
InstallationMedia: Ubuntu-Server 14.04 LTS "Trusty Tahr" - Release amd64 (20140416.2)
IwConfig: Error: [Errno 2] No such file or directory: 'iwconfig'
Lsusb:
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 004 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 003 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 002 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
MachineType: QEMU Standard PC (i440FX + PIIX, 1996)
ProcFB: 0 VESA VGA
ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-3.13.0-29-generic root=UUID=9068010d-8332-47c8-ae62-ccc62ca57290 ro
RelatedPackageVersions:
linux-restricted-modules-3.13.0-29-generic N/A
linux-backports-modules-3.13.0-29-generic N/A
linux-firmware N/A
RfKill: Error: [Errno 2] No such file or directory: 'rfkill'
SourcePackage: linux
UpgradeStatus: No upgrade log present (probably fresh install)
dmi.bios.date: 01/01/2011
dmi.bios.vendor: Bochs
dmi.bios.version: Bochs
dmi.chassis.type: 1
dmi.chassis.vendor: Bochs
dmi.modalias: dmi:bvnBochs:bvrBochs:bd01/01/2011:svnQEMU:pnStandardPC(i440FX+PIIX,1996):pvrpc-i440fx-2.0:cvnBochs:ct1:cvr:
dmi.product.name: Standard PC (i440FX + PIIX, 1996)
dmi.product.version: pc-i440fx-2.0
dmi.sys.vendor: QEMU
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1327563/+subscriptions
References