Собираем утилиту busytest из cifs/busytest.c в репозитории git.office:/projects/wine/wine-etersoft-devel.git Монтируем cifs-раздел так: mount -t cifs //winxp/Rarus /mnt/cifs -o user=guest,pass=,rw,iocharset=utf8,noperm,wine или так: mount -t cifs //winxp/Rarus /mnt/cifs -o user=guest,pass=,rw,iocharset=utf8,noperm,strictcache,forcemand winxp - машина с Windows XP Запускаем на cifs-разделе и нажимаем Ctrl-C после появления третьей звёздочки: $ ./busytest fy * * * ^C После этого файл не открывается: $ cat fy cat: fy: Текстовый файл занят Файл начинает открываться только после перемонтирования раздела. Воспроизводится на машинах atlant (3.0.6-std-def-alt1) и euclid (3.0.7-std-def-alt1). На обоих стоит etercifs-5.1.4-alt1.
Это раньше работало на предыдущих ядрах?
На 2.6.32-ovz-el-alt38 с etercifs-5.1.2-alt1 проблемы нет.
Проблема существует с ядра 2.6.38. Возникает она потому, что теперь в данном ядре изменился режим обработки сообщений: ждём ответ от сервера беконечно и тестируем его echo запросами; в случае, если сервер не отвечает на echo запросы, переустанавливаем соединение. Это изменения повлекло за собой то, что цикл ожидания ответа от сервера можно прервать (раньше он только сам прерывался после выставленного таймаута). Теперь, когда мы прерываем операцию, на сервер отсылается nt_cancel сообщение и оно не всегда успевает добраться до сервера раньше, чем тот ответит на запрос. amorozov, данная проблема проявляется в реальной работе приложений или это было случайно поймано на синтетических тестах? Как решение, можно сделать специальный хак, что если мы получаем open response и не находим объекта ожидающего данный пакет, то конструируем запрос на закрытие. Такому же поведению отвечает команда установки блокировки.
> amorozov, данная проблема проявляется в реальной работе приложений или это было > случайно поймано на синтетических тестах? Тест синтетический. В реальной работе такого пока не видел.
lav@, пока выставляю здесь решена (отложена надолго),
Закрыта.
