Created attachment 3644 [details] Программы для воспроизведения проблемы 1-я машина: Linux lav.office.etersoft.ru 2.6.30-std-def-alt1 #1 SMP Thu Jun 25 07:23:18 UTC 2009 i686 GNU/Linux 2-я машина: Linux atlant.office.etersoft.ru 2.6.30-std-def-alt3 #1 SMP Sat Jul 4 07:09:22 UTC 2009 i686 GNU/Linux На 2-й машине монтируется директория по nfs: # mount -t nfs lav:/net/exports/test /mnt/test На 1-й машине устанавливаем read-блокировку: $ ./linlock r test_file press Ctrl-C... На 2-й машине пытаемся установить write-блокировку: $ ./linlock w test_file fcntl: Resource temporarily unavailable Всё как и должно быть. Но при этом F_GETLK говорит, что ничего не должно мешать поставить write-блокировку: $ ./lockinfo test_file F_UNLCK SEEK_SET start 0 len 0 Если устанавливать read-блокировку на 2-й машине, то на 1-й она с помощью F_GETLK видна. linlock и lockinfo в аттаче.
буду думать. А в инете на тему пишут? Вопрос кстати, там надеюсь lockd запущен везде?
> А в инете на тему пишут? Не видел. > Вопрос кстати, там надеюсь lockd запущен везде? Повторил эксперимент. Проверил, что lockd присутствует в списке, выдаваемом ps aux. В этот раз 1-й машина: Linux altlinux.lin-test 2.6.32-std-def-alt16 #1 SMP Tue Jul 6 22:29:03 UTC 2010 i686 GNU/Linux 2-я машина: Linux atlant.office.etersoft.ru 2.6.32-std-def-alt15 #1 SMP Wed Jun 23 15:13:44 UTC 2010 i686 GNU/Linux Всё по-прежнему.
Возможно, стоит проверить на Ubuntu или CentOS. 2piastry: возьмёшься подтвердить ситуацию, и, быть может, обсудить в lkml, вплоть до исправляющего патча.
Выяснил, что проблема появилась между 2.6.21 и 2.6.22-rc1, а также то, что баг зависит только от версии ядра на клиентской стороне. Создал баг в багзилле ядра: https://bugzilla.kernel.org/show_bug.cgi?id=23892
Кстати, лучше всего проверить наличие всего необходимого в выводе # rpcinfo -p localhost У меня иногда не хватало nlockmgr при всём запущенном.
http://lxr.free-electrons.com/source/fs/lockd/clntproc.c?a=m68knommu#L439 Вот тут мы явно выставляем его в ноль. Что довольно странно. Напрашивается: fl->fl_pid = req->a_res.lock.fl.fl_pid.
Патч, решающий багу добавлен в 32 и 33 ядра. Так же он уже в upstream разработчика NFS клиента ядра.
(В ответ на комментарий №7) > Патч, решающий багу добавлен в 32 и 33 ядра. Так же он уже в upstream > разработчика NFS клиента ядра. Идёт ли речь о ядрах в Сизифе? В любом случае, как я понимаю, есть более точная адресация для ядер (вида 2.6.33.X).
Так. Цифру 33 следует читать как 36 :) Патч добавлен в очередь, из которой патчится stable релизы. В долгоподдерживаемое 32 ядро тут: http://git.kernel.org/?p=linux/kernel/git/longterm/longterm-queue-2.6.32.git;a=commitdiff;h=3858761cadee2b9bbb19695a33ec6dcd2f496b87 В текущее стабильное 36 ядро тут: http://git.kernel.org/?p=linux/kernel/git/stable/stable-queue.git;a=commit;h=0c2956ff492e99e11a95ddcdae84054a85971590 В какой номер релиза этих ядер войдёт патч - неизвестно. Так же следует ожидать его в грядущем 38 ядре.
Так же судя по: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=21ac19d484a8ffb66f64487846c8d53afef04d2b http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=38971ce2fac484249d697fe48a9b0851a0b62572 патч уже в основной ветке. Самый первый таг после этих коммитов - http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=tag;h=refs/tags/v2.6.37-rc7 То есть, начиная с 2.6.37-rc7, патч уже в ядре.
(В ответ на комментарий №9) ... > В какой номер релиза этих ядер войдёт патч - неизвестно. Так же следует ожидать > его в грядущем 38 ядре. 37 ядре.
