Bug 29233

Summary: На ядрах 3.10.x крайне медленно монтируется NFS
Product: Sisyphus Reporter: Evgenii Terechkov <evg>
Component: kernel-image-std-defAssignee: Vitaly Chikunov <vt>
Status: NEW --- QA Contact: qa-sisyphus
Severity: normal    
Priority: P3 CC: kernelbot, vt
Version: unstable   
Hardware: all   
OS: Linux   
Attachments:
Description Flags
Отчёт system-report о машине none

Description Evgenii Terechkov 2013-07-28 14:47:25 MSK
Created attachment 5898 [details]
Отчёт system-report о машине

После обновления на ядра 3.10.1/3.10.3-alt1 стали очень медленно монтироваться NFS-шары (через autofs). Причём на каждую попытку точку монтирования через некоторое время ( секунд по прикидкам) после обращения в логе появляется следующая ругань:

Jul 28 18:41:45 thinkpad kernel: [ 1072.863044] RPC: AUTH_GSS upcall timed out.
Jul 28 18:41:45 thinkpad kernel: [ 1072.863044] Please check user daemon is running.

и только потом происходит успешное монтирование и вход в каталог. Пользоваться автомонтированием стало положительно невозможно.

Откат на ядро 3.9.6-alt1 решает проблему.
Comment 1 Evgenii Terechkov 2013-07-29 06:47:21 MSK
Проявляется и на 3.10.3-std-pae-alt1 (i586, другая машина).
Comment 2 Evgenii Terechkov 2013-07-30 14:54:56 MSK
То же и на 3.10.4-std-pae-alt1
Comment 3 Michael Shigorin 2013-07-30 15:51:28 MSK
Опция монтирования nfsvers=3 что-либо меняет?

Вообще что-то смутно припоминается про переприкрученность krb5, см. тж. http://joshuawise.com/kerberos-nfs
Comment 4 Evgenii Terechkov 2013-07-30 17:19:06 MSK
Да, nfsvers=3 проблему решает.

nfs(5) и  rpc-server-gss.txtrpc-server-gss.txt из документации ядра объясняют, что сначала идёт попытка монтировать NFSv4 а уже потом NFSv3 и во время первой попытки ядро ждёт ответа от одной из двух реализации rpc-gss сервера/прокси в пользовательском пространстве. Насколько понимаю, старая реализация у нас собрана в пакете nfs-server в виде rpc.svcgssd, а новая не собрана. Видимо, в новом ядре что-то изменилось, что дало такой эффект.

Имхо, это стоило бы починить.