Bug 22995

Summary: На ядрах >18: qword_eol: fflush failed: errno 2
Product: Sisyphus Reporter: Anton V. Boyarshinov <boyarsh>
Component: nfs-serverAssignee: Sergey Bolshakov <sbolshakov>
Status: CLOSED WONTFIX QA Contact: qa-sisyphus
Severity: critical    
Priority: P3 CC: aen, cas, ldv, legion, sbolshakov, vitty
Version: unstableKeywords: distro-blocker
Hardware: all   
OS: Linux   
Bug Depends on:    
Bug Blocks: 22919    

Description Anton V. Boyarshinov 2010-02-19 14:21:11 MSK
На ядрах новее 2.6.18 при попытке монтирования по NFS, сервер возвращает Permission Denied, а в его логах появляется такая запись:

mountd[9853]: qword_eol: fflush failed: errno 2 (No such file or directory)

насколько я могу судить "service nfs restart" исправляет проблему до следующей перезагрузки.

Протестировано на ядрах: 30-std-def, 32-std-def,
32-un-def, 27-ovz-smp

Предполагаю, что проблема может быть в несоответствии ожидаемого поведения между userspace и ядром.
Comment 1 Sergey Bolshakov 2010-02-19 14:55:01 MSK
было бы уместно привести версии ядер и nfs-* на клиенте и сервере,
а также опции монтирования на клиенте и содержимое /etc/exports
с указанием файловых систем сервера.
Comment 2 Anton V. Boyarshinov 2010-02-19 15:04:19 MSK
(В ответ на комментарий №1)
> было бы уместно привести версии ядер и nfs-* на клиенте и сервере,
> а также опции монтирования на клиенте и содержимое /etc/exports
> с указанием файловых систем сервера.

Это на изкоробочном office-server происходит.
Сервер:
------------------------------
cat /etc/exports
/srv/public -ro,insecure,no_subtree_check *
/srv/share -rw,insecure,fsid=0,sec=krb5 *
-----------------------------
# mount
/dev/sda1 on / type ext3 (rw,relatime)
proc on /proc type proc (rw,noexec,nosuid,gid=19)
sysfs on /sys type sysfs (rw)
udevfs on /dev type tmpfs (rw)
devpts on /dev/pts type devpts (rw)
shmfs on /dev/shm type tmpfs (rw)
tmpfs on /tmp type tmpfs (rw,nosuid)
/dev/mapper/system-home on /srv type ext3 (rw,nosuid,nodev,relatime,usrquota,grpquota)
rpc_pipefs on /var/lib/nfs/rpc_pipefs type rpc_pipefs (rw)
nfsd on /proc/fs/nfsd type nfsd (rw)
-----------------------
 # rpm -qa | grep 'nfs-*'
nfs-server-1.1.6-alt1
nfs-clients-1.1.6-alt1
libnfsidmap-0.22-alt1
nfs-utils-1.1.6-alt1
----------------------
Опробованные перечислены в первом сообщении.

Клиент:
ядро 30-std-def-15
Версии nfs-* аналогичные серверу (одна сборка)
mount -t nfs 192.168.2.1:/srv/public /mnt/test -o nolock
mount.nfs: access denied by server while mounting 192.168.2.1:/srv/public
Comment 3 Sergey Bolshakov 2010-02-19 16:49:22 MSK
ресолвер настроен ?
ip <-> hostname в обе стороны.
Comment 4 Anton V. Boyarshinov 2010-02-24 12:48:36 MSK
(В ответ на комментарий №3)
> ресолвер настроен ?
Да, на обеих машинах всё хорошо в обе стороны.

> ip <-> hostname в обе стороны.
Сервер:
[root@c204 ~]# host 192.168.2.254
254.2.168.192.in-addr.arpa domain name pointer host-254.stend2.altlinux.ru.
[root@c204 ~]# host host-254.stend2.altlinux.ru
host-254.stend2.altlinux.ru has address 192.168.2.254

Клиент:
[root@host-254 ~]# host 192.168.2.1
1.2.168.192.in-addr.arpa domain name pointer c204.stend2.altlinux.ru.
[root@host-254 ~]# host c204.stend2.altlinux.ru
c204.stend2.altlinux.ru has address 192.168.2.1
Comment 5 Dmitry V. Levin 2010-02-24 21:33:59 MSK
А почему сервер не справлется с вычислением uuid?
Comment 6 Sergey Bolshakov 2010-02-25 00:40:53 MSK
как некоторым уже известно, в этом случае workaround -- явное указание fsid.
Comment 7 Dmitry V. Levin 2010-02-25 01:00:30 MSK
(In reply to comment #6)
> как некоторым уже известно, в этом случае workaround -- явное указание fsid.

А почему, собственно говоря, сервер не справляется с вычислением uuid?  Если обычный mount вычисляет и монтирует файловую систему, то что мешает nfs-серверу вычислить этот же самый uuid?
Comment 8 Sergey Bolshakov 2010-02-25 01:19:32 MSK
обычно сервер справляется с вычислением uuid -- и даже в этом конкретном случае, достаточно лишь выдержать некоторую небольшую паузу.
почему она в этом случае кажется необходимой -- вопрос открытый,
я бы не прочь и сам услышать объяснения от понимающих в udev/libblkid.
Comment 9 Dmitry V. Levin 2010-02-25 01:41:24 MSK
(In reply to comment #8)
> обычно сервер справляется с вычислением uuid -- и даже в этом конкретном
> случае, достаточно лишь выдержать некоторую небольшую паузу.
> почему она в этом случае кажется необходимой -- вопрос открытый,
> я бы не прочь и сам услышать объяснения от понимающих в udev/libblkid.

Речь идёт о nfs/utils/mountd/cache.c ?
Comment 10 Alexey Gladkov 2010-02-25 01:53:27 MSK
(В ответ на комментарий №8)
> обычно сервер справляется с вычислением uuid -- и даже в этом конкретном
> случае, достаточно лишь выдержать некоторую небольшую паузу.

На этом месте я хотел бы вмешаться:

http://www.spinics.net/lists/util-linux-ng/msg02852.html

Тред не очень длинный. Суть в том, что blkid слишком долго и не эффективно сканирует устройство. Из-за этого некоторые программы отваливались по таймауту.

Ряд оптимизаций были сделаны в libblkid в новой версии util-linux-ng-2.17.1, которого ещё в сизифе нет.
Comment 11 Sergey Bolshakov 2010-02-25 01:54:42 MSK
> Речь идёт о nfs/utils/mountd/cache.c ?
да
Comment 12 Dmitry V. Levin 2010-02-25 01:58:50 MSK
(In reply to comment #10)
> (В ответ на комментарий №8)
> > обычно сервер справляется с вычислением uuid -- и даже в этом конкретном
> > случае, достаточно лишь выдержать некоторую небольшую паузу.
> 
> На этом месте я хотел бы вмешаться:
> 
> http://www.spinics.net/lists/util-linux-ng/msg02852.html
> 
> Тред не очень длинный. Суть в том, что blkid слишком долго и не эффективно
> сканирует устройство. Из-за этого некоторые программы отваливались по таймауту.
> 
> Ряд оптимизаций были сделаны в libblkid в новой версии util-linux-ng-2.17.1,
> которого ещё в сизифе нет.

Очень слабо верится в то, что lvm-over-raid настолько медленный.  К тому же обычному mount'у ведь ничто не мешает смонтировать файловую систему по uuid до mountd.
Comment 13 Alexey Gladkov 2010-02-25 02:19:27 MSK
(В ответ на комментарий №12)
> Очень слабо верится в то, что lvm-over-raid настолько медленный.  К тому же
> обычному mount'у ведь ничто не мешает смонтировать файловую систему по uuid до
> mountd.

Я не специалист в nfs и хотел проинформировать о проблемах производительности... раз речь зашла о libblkid.
Comment 14 Anton V. Boyarshinov 2010-02-25 12:38:54 MSK
Исходная проблема, судя по всему, не имеет отношения к fsid=

[root@c204 ~]# cat /etc/exports
/srv/public -ro,insecure,no_subtree_check,fsid=1 *
/srv/share -rw,insecure,fsid=0,sec=krb5 *
-----------------------------------------
tail  /var/log/messages 
Feb 25 12:36:24 c204 mountd[14715]: authenticated mount request from 192.168.2.254:724 for /srv/public (/srv/public)
Feb 25 12:36:24 c204 mountd[14715]: qword_eol: fflush failed: errno 2 (No such file or directory)
Feb 25 12:36:26 c204 mountd[14715]: authenticated mount request from 192.168.2.254:1017 for /srv/public (/srv/public)
Feb 25 12:36:26 c204 mountd[14715]: qword_eol: fflush failed: errno 2 (No such file or directory)
Comment 15 Sergey Bolshakov 2010-02-25 13:32:27 MSK
какой удар от классика
Comment 16 Sergey Bolshakov 2010-02-27 16:33:44 MSK
altlinux-5.0.0-20100226-office-server-x86_64-ru-install-cd.iso
не повторяется.
Comment 17 Anton V. Boyarshinov 2010-02-27 17:06:12 MSK
> altlinux-5.0.0-20100226-office-server-x86_64-ru-install-cd.iso
> не повторяется.
Пока мы не знаем: с какими именно особенностями c204 связано наличие на нём этой проблемы (разбиение диска, тайминги etc), но на нём это железно воспроизводится -- значит то, что где-то работает -- не показатель.. На ham1 мы иногда ловили эту ошибку. Именно иногда. А на c204 она 100% воспроизводится.
Comment 18 Anton V. Boyarshinov 2010-03-04 15:54:00 MSK
После двойной переустновки стенда не воспроизводится
Comment 19 AEN 2010-03-04 16:01:38 MSK
(В ответ на комментарий №18)
> После двойной переустновки стенда не воспроизводится

WORKSFORME ?