Bug 6777

При работе с vbox контейнером обнаружил, что большинство машин не имеет доступ к себе по различным причинам: неправильный айпи, отсутствие айпи и ностнэйма (вывод vbox -l на euclid). Получилось настроить шару только на
192.168.4.232 SUSE 11.2
192.168.4.219 Mandriva 2010.0 x86_64
192.168.4.239 Ubuntu 10.04

37 яро получилось поставить только на Ubuntu 9.10 (ещё была доступна Ubuntu 10.04, но она использовалась ещё кем-то), после чего та ушла в даун и больше не возвращалась. На этом решено было закончить с vbox-контейнером до разъяснения ситуации.

Скомпилировал Samba-3.6-pre1 и протестировал у себя на ноуте. Так же протестировал ещё раз с Ubuntu 10.10. Оба теста прошли успешно.

Попробовал с Windows 7. Проблема себя показала. Провёл исследование этой проблемы (см вот это тред http://www.mail-archive.com/linux-cifs@vger.kernel.org/msg00805.html). Выяснилось, что сервер смотрит на поле OplockLevel в ack со стороны клиента на oplock break. В документации по этому поводу ничего конкретного не сказано. Сделал небольшой патч, который исправляет поведение клиента - подтверждаем значение OplockLevel в ack (а не игнорируем, как сейчас), выставил небольшую задержку, чтобы сервер успевал отослать оплок брейк после write запроса клиенту, и тест прошёл.

Таким образом предположение Jeff'а Laython'a подтвердилось. Буду писать об этом в апстрим  и прокидывать патч.

Created attachment 2095 [details]
Скрипт, версия 2

Created attachment 2096 [details]
Скрипт, версия 3

Оформил патч, решающий данную проблему. Заодно выявил ещё одну проблему с оплоками, решение которой тоже включил в этот патч. Как патч одобрят, соберу новые сборки etercifs-4.7.x (c writepages патчем и без него).

Попробовал vbox -l на euclid. Без изменений.
Примеры неправильной работы:
1) ||running | ALTLinux 5.1 | 92934d16-b2d8-4bf6-8d8f-f77bc641017e |                  alt-linux-5-1 | 192.168.4.101 ||

Не отзывается по айпи 192.168.4.101:

[piastry@euclid ~]$ ping 192.168.4.101
PING 192.168.4.101 (192.168.4.101) 56(84) bytes of data.
From 192.168.0.23 icmp_seq=1 Destination Host Unreachable

2) || saved | Ubuntu 10.10 | 97c74176-376e-4c69-8a74-9a7ad9f7a7a1 |                                |                 ||

Айпи и хостнэйм вообще не указаны.

Собрал Samba-4.0.0-alpha14 и протестировал на ней. Результаты Windows 7 подтвердились.

В процессе тестирования натолкнулся на багу Samba. Сервер может выдать клиенту оплок на чтение в случае если этот файл уже открыт другим клиентом, установившим на него блокировку на запись. В результате когда мы читаем первым клиентов (всю страницу), чтение падает с ошибкой. На Windows 7 поведение правильное - клиенту в таком случае не выдаётся оплок. Буду более тщательно разбираться и писать в апстрим Samba в случае подтверждения.

Проблема проявляется только на Samba-4.0.0. Посмотрел код Samba - не нашёл похожей проверки ни в исходниках 3-ей, ни в исходниках 4-ой версии. Дальше планирую написать разработчикам с просьбой прокомментировать данную ситуацию.

Завёл багу https://bugzilla.samba.org/show_bug.cgi?id=7923.

Обсудил с Джефон Лэйтоном ситуацию по патчу и получил замечание по патчу с оплоками. Поправил патч, потестировал, пересоздал ветки и залил их на git.eter форсом.

Завёл багу http://bugs.etersoft.ru/show_bug.cgi?id=6818, без решения которой, решение текущей баги представляется маловероятным.

(В ответ на comment #11)
> Завёл багу http://bugs.etersoft.ru/show_bug.cgi?id=6818, без решения которой,
> решение текущей баги представляется маловероятным.

Паша, может быть тебе имеет смысл использовать локальные виртуалки для своих тестов? Для этого было бы желательно найти подготовленные vdi образы.

(В ответ на comment #12)
> (В ответ на comment #11)
> > Завёл багу http://bugs.etersoft.ru/show_bug.cgi?id=6818, без решения которой,
> > решение текущей баги представляется маловероятным.
> 
> Паша, может быть тебе имеет смысл использовать локальные виртуалки для своих
> тестов? Для этого было бы желательно найти подготовленные vdi образы.

Мне кажется нет смысла поднимать дублирующую инфраструктуру всего лишь из-за того, что существующая работает неправильно. Если привести её в порядок, то всем будет удобно пользоваться одной. Это искоренит проблемы вида: "у меня всё работает - проблема у вас локальная" - тестер и разработчик смогут говорить об одном и том же окружении.

Создал скрипты, воспроизводящие все три проблемы Samba-3, которые исправляются вышеописанными тремя патчами. Далее надо портировать их в RECT.

Протестировал на тестах RECT. Cервера из Ubuntu 10.04, Fedora 13 Russian, OpenSuse 11.3 прошли тесты.

Обнаружил неправильное поведение тестов при работе с  Samba в OpenSuse 11.2. Далее буду разбираться, в чём тут проблема.

Завершил тестирование.
Итоги: все сервера кроме вышеописанной версии из OpenSUSE-11.2 прошли тесты на оплоки при работе с новым режимом strict cache.

По поводу OpenSUSE-11.2: данная версия работает неправильно и со старым direct режимом, хотя количество непройденных тестов для этих режимов различается на один. Проверил данный тест и выяснил, что Samba при определённой раскладе записывала данные не в начало файла, а в конец. Скорее всего это обусловлено последовательностью вызовов записи (так как в этих режимах они отсылаются не в одинаковом порядке). Таким образом данную сборку предлагаю считать не поддерживаемой для обоих режимов работы:
guest@linux-crjs:~> /usr//sbin/smbd -V
Version 3.4.3-3.3.1-2341-SUSE-SL11.2

Бага решена.

Принято.

Закрываю.