При работе с windows сервером в драйвере cifs отсутствует реализация posix семантики снятия блокировок во время закрытия файла. При закрытии одного из файловых дескрипторов блокировки, привязанные к другим файловым дескрипторам, созданным одним и тем же процессом не снимаются, что противоречит POSIX семантике.
Решение видится следующее: построить дерево из пидов, каждому из которых будет соответствовать список блокировок. Это обеспечит быстрое удаление всех блокировок, привязанных к данному пиду - удаляется узел из дерева. При удалении же какой-то одной конкретной блокировки, мы просто пробегаемся по списку пида и удаляем все блокировки, находящиеся внутри неё.
Ветка репозитория, где ведётся работа. http://git.etersoft.ru/people/piastry/packages/?p=etercifs.git;a=commitdiff;h=d6090073dcf72f3db9e05aa4c7f744f1a20c4c37
Думаю, что из рабочего дерева, с которым можно будет куда-то выходить, стоит исключить эскпериментальные коммиты с архаизмами вида '\r' и комментариев со странным кодом: +int main() {\r + int n, m;\r + //freopen("input", "rt", stdin);\r + //freopen("output", "wt", stdout);\r + pid_tree *head = NULL;\r + while(1) {\r + string s;\r + cin >> s;\r + if (s == "insert") {\r + __u64 pid, offset, len;\r Да и реализацию функций в заголовочные файлы кидать тоже не стоит... А кроме прочего с локальными функциями не стоит забывать про спецификатор static... Я бы не хотел видеть код из текущего коммита в своих ветках. Его стоит исправить...
Исправлено. http://git.etersoft.ru/people/piastry/packages/?p=etercifs.git;a=shortlog;h=refs/heads/lock_on_close
(In reply to comment #4) > Исправлено. > http://git.etersoft.ru/people/piastry/packages/?p=etercifs.git;a=shortlog;h=refs/heads/lock_on_close > Странные коммиты, я думаю, стоит вообще исключить из истории. Как быть с кодом в заголовочном файле? Его там быть не должно - это же не C#.
Разбросал код. Набросал реализацию posix поведения при закрытии файлов. Теперь надо буду тестировать и отлавливать ошибки, если таковые найдутся. По поводу странных коммитов не вижу ничего страшного если они и будут. Это тестовый репо, не больше, не меньше.
Переехал в новый бранч. http://git.etersoft.ru/people/piastry/packages/?p=cifsLockOnClose.git;a=summary
На локальных своих тестах заработала след функциональность: Два процесса - 1 и 2 1 открывает файл - дескриптор file1 1 открывает файл - дескриптор file2 2 открывает файл - дескриптор file3 1 устанавливает блокировку через file1 2 пытается установить блокировку через file3, зависая в ожидании 1 закрывает дескриптор file2, 2 - сразу же получает доступ к файлу, устанавливая блокировку на file3 Вышеописанное соответствует поведению posix.
(In reply to comment #8) > На локальных своих тестах заработала след > функциональность: [...] > Вышеописанное соответствует поведению posix. > Нужно сделать соответствующую ветку ядра в нашем git для cifs, а также собрать тестовую сборку etercifs и протестировать с помощью rect.
Нашел в коде типа bool (например bool USE_TREE = true; ). С этим на ядрах < 2.6.23 собираться не будет. Надо изменить на unsigned USE_TREE = 1; и проверить собираемость на всех ядрах.
... И код отформатирован не так, как он в исходниках ядра форматируется. Вместо табов - пробелы.
Репозиторий разработки: http://git.etersoft.ru/people/piastry/packages/?p=cifs-2.6.git;a=summary все ветки *-locks Решены проблемы с типами данных и оформлением исходного кода. Проверена собираемость всех веток.
Пакет для тестирования тут ftp://ftp.etersoft.ru/pub/Etersoft/LINUX@Etersoft/Boxes/etercifs-testing/noarch/RPMS.default/etercifs-4.1.1-alt1.testing1.noarch.rpm Git тут (ветка testing): http://git.etersoft.ru/people/kipruss/packages/?p=etercifs.git;a=shortlog;h=refs/heads/testing
etercifs-4.1.1-alt1.testing1 rect-slice-0.0.11-alt1 rect-slave-0.0.11-alt1 python-module-RECT-0.0.11-alt1 Клиенты: start: LS:tcp -h 192.168.33.9 -p 13666 start: LS:tcp -h localhost -p 13555 start: LS:tcp -h valhalla -p 13666 Сервера: start: //192.168.33.1/upload start: //192.168.33.9/share С опцией forcemand тест на снятие блокировки после закрытия файла (DualSetLockOnLock.testReadAfterCloseAfterLock) падает везде. Без опции forcemand тест падает только при работе с windows сервером. Падает на операции saferead после закрытия файла. (Для linux - permission denied)
Я правильно понимаю, что первым слейвом использовался слейв на windows? Если это так, то всё правильно, ибо мой патч исправляет posix поведение linux драйвера, а следственно, его и нужно использовать первым слейвом. Тестировать на linux сервере следует только с опцией forcemand, иначе код моего пачта просто не будет выполняться. Но там и так всё работало - и без моего патча. Тестируйте в след конфигурациях: L-L on Windows server L-W on Windows server (цель патча) L-L on Linux server L-W on Linux server (для проверки на наличие багов)
Нет. Первым слейвом везде использовался linux. Получилось как-то все наоборот. В случае linux-сервера с опцией forcemand тест падал, без нее проходил. В случае windows-сервера с опцией forcemand тест падал, без нее тоже падал.
http://wiki.etersoft.ru/RECT/Testtest?v=mk1 - тестовая(временная) страница на вики. Туда сохранила результаты этого теста
После обновления ядра все заработало: тест прошел (2.6.27-std-def-alt11)
Новая версия со свежими Пашиными изменениями: У нас: //server/pub/Boxes/etercifs-testing/noarch/RPMS.defaultet/ercifs-4.1.2-alt1.testing1.noarch.rpm И в Питере: ftp://ftp.etersoft.ru/pub/Etersoft/LINUX@Etersoft/Boxes/etercifs-testing/noarch/RPMS.default/etercifs-4.1.1-alt1.testing1.noarch.rpm
(In reply to comment #19) не > //server/pub/Boxes/etercifs-testing/noarch/RPMS.defaultet/ercifs-4.1.2-alt1.testing1.noarch.rpm а //server/pub/Boxes/etercifs-testing/noarch/RPMS.default/etercifs-4.1.2-alt1.testing1.noarch.rpm
Тот же тест на новом etercifs успешно пройден.
(In reply to comment #21) > Тот же тест на новом etercifs успешно пройден. > Ждем заключения экспертов по вопросу перехода патчей в основную ветку. :)
Ссылка на страничку данной проблемы: http://wiki.office.etersoft.ru/testing/cifs/ProblemRemoveLockWin?v=x17
Проведена проверка кода, обнаружены ошибки.
Проблемы решены. Последняя версия исходников на git.etersoft.ru
(In reply to comment #25) > Проблемы решены. Последняя версия > исходников на git.etersoft.ru > Собран пакет ftp://ftp.etersoft.ru/pub/Etersoft/LINUX@Etersoft/Boxes/etercifs-testing/noarch/RPMS.default/etercifs-4.1.2-alt1.testing2.noarch.rpm который ожидает тестирования. Наше тестирование RECTом проблем не выявило и подтвердило ожидаемый эффект от изменений. Если через неделю проблемы не будут выявлены, то изменения попадут в основную ветку. Ссылка на гит: http://git.etersoft.ru/people/kipruss/packages/?p=etercifs.git;a=shortlog;h=refs/heads/testing
Хотелось бы знать что с этими изменениями делать. Релиз 4.2 он не попал, в отличие от остальных изменений и перед следующим релизом я опять ставлю вопрос про данный патч. Что с ним делать? Было бы здорово получить ответ до понедельника, 30 марта.
А можно получить какие-либо замечания о том, почему фигурирует именно Windows-сервер? Проблема, как я знаю, характерна для любого CIFS-сервера.
Нет. Samba server с включенными linux ext сам снимает блокировки. Если же мы монтируем его шару с опцией forcemand или используем windows сервер, то появляется проблема, описанная в баге.
(In reply to comment #27) > Хотелось бы знать что с этими изменениями > делать. Релиз 4.2 он не попал, в отличие от > остальных изменений и перед следующим > релизом я опять ставлю вопрос про данный > патч. Что с ним делать? Включаем в следующую сборку.
Выставляю статус решена.
см. http://bugs.etersoft.ru/show_bug.cgi?id=3755#c1 выпущен 4.3.0, содержащий патчи, решающие данную проблему.
