Created attachment 2094 [details] Скрипт, выявляющий проблемы Samba Режим strictcache, разработанный при решении этой баги (http://bugs.etersoft.ru/show_bu7g.cgi?id=6227) сильно зависит от правильного поведения Samba сервера по выдаче оплоков. Было замечено неправильное поведение в альфе 4-ой Samba и pre 3.6 Samba. Потому надо проверить Samba различных версий. 1) Ubuntu 10.04. 2) Ubuntu 10.10. 3) Fedora 13, 14. 5) ALT Linux 5.1. 6) ALT Linux Sisyphus. 7) SUSE 11.2. 8) Mandriva 2010.1. 9) Samba 3.6.(upstream). 10) Samba 4.0 (upstream). При обнаружении неточности работы надо довести её до сведения разработчиков. Скрипт для тестирования в приложении.
При работе с 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 Бага решена.
Принято.
Закрываю.
