Согласно http://bugs.etersoft.ru/show_bug.cgi?id=7302#c16 и обсуждению с lav@ решено вынести в отдельную багу.
Реализовал механизм кэширования блокировок на основе старых разработок (из баги #5442): http://git.etersoft.ru/people/piastry/packages/?p=cifs-2.6.git;a=shortlog;h=refs/heads/etersoft-lock-cache Далее планируется провести более подробное тестирование данного функционала.
Переосмыслил дизайн. Нашёл ошибки связанные с расширением и data races. Переписал реализацию и провёл первоначальное тестирование. Далее требуется провести более подробное синтетическое тестирование.
Разобрался как хранятся posix блокировки в vfs и использовал данный мезанизм для реализации кэширования блокировок в стиле posix. http://git.etersoft.ru/people/piastry/packages/?p=cifs-2.6.git;a=shortlog;h=refs/heads/etersoft-lock-cache Провёл тестирование реализованного функционала (mandatory и posix варианты) с потощью RECT и Connectathon Test suite соответственно с Samba-3.6.0-alt1 с опциями kernel oplocks = no и level2 oplocks = yes. http://git.etersoft.ru/people/piastry/packages/?p=cifs-2.6.git;a=shortlog;h=refs/heads/v3.0-lock-cache В ходе работ обнаружил ошибку в выборе исходников ядра пакетом etercifs, что поправил (войдёт в следующую версию пакета). http://git.etersoft.ru/people/piastry/packages/?p=etercifs.git;a=shortlog;h=refs/heads/master Далее можно собирать тестовую версию пакета etercifs и тестировать с WINE.
Просмотрел код и обнаружил некоторые недочёты в сематике и стиле. Провёл рефакторинг кода. Добавил новый функионал по быстрому снятию блокировок при закрытии (запросы отправляются партиями). Закоммитил изменения в новую ветку lock-cache-to-kernel (http://git.etersoft.ru/people/piastry/packages/?p=cifs-2.6.git;a=shortlog;h=refs/heads/lock-cache-to-kernel). Далее займусь портированием патчей в v3.0-lock-cache и более тщательным тестированием.
Портировал патчи из lock-cache-to-kernel. Изучал различие в поведении mandatory и posix блокировок. Обнаружил ошибки и недочёты, поправил стиль кода. Создал реализацию, которая полностью удовлетворяет mandatory семантике (текущая не является таковой). Так же поднял в рассылке linux-cifs тему о статусе данного кода в апстрим. Итого сейчас имею две актуальные ветки: v3.0-lock-cache v3.0-lock-cache-fullmand Протетированно с помощью RECT (mandatory блокировки) Connectathon Test suite (posix блокировки).
Сделал некоторые изменения в описании патчей. Исследовал работу вызова unlock в связке WINE+CIFS - текущая реализация некорректно работает с пересекающимися блокировками. По результатам обсуждения в devel@, создал ещё две ветки etersoft-fullmand и v3.0-fullmand с исправлениями для вызова unlock. Собрал две сборки 5.1.0 ( v3.0-fullmand ) и 5.1.1 ( v3.0-lock-cache-fullmand ) для тестирования.
Исправил ошибку из http://bugs.etersoft.ru/show_bug.cgi?id=7685#c4, поправил стиль кода, протестировал с помощью RECT обе ветки (c fullmand и без). По результатам обсуждения в рассылке отправил туда патчи без fullmand (так как режим fullmand не соответствует изначальной цели, преследуемой в оригинальном cifs.ko).
(В ответ на comment #8) ... > По результатам обсуждения в рассылке отправил туда патчи без fullmand Первые два патча в аптрим (http://bugs.etersoft.ru/show_bug.cgi?id=6517#c54).
В третьем патче обнаружена ошибка залипания блокировки. Поправил 3 и 5 патчи, протестировал и отправил рассылку исправленные версии.
Остальные патчи из данной серии приняты в апстрим
Тестирование нового функционала прошло успешно: http://bugs.etersoft.ru/show_bug.cgi?id=7685
Закрываю.
Обнаружил некоторые недостатки в патчах, принятых в апстрим.
Создал и протестировал три патча, исправляющие вышеуказанные недостатки. Отправил в рассылку.
Включил вышеописанные патчи в основной код etercifs. Выпустил 5.1.3 сборку для тестирования.
Обсудил с amorozov@ ситуацию с разблокированием. Если у нас есть код вида: fd = open(filename) pid = fork() if (pid == 0) { lock(fd) } else { sleep(10) lock(fd) } то блокировка поставленная в дочернем процессе не снимется в текущей реализации. Таким образом, любое приложение, запущенное вайн-приложением и установившее блокировки на унаследованный файл не сможет их снять, если не укажет снятие явно (вызовом unlock с тем же смещением и длиной блокировки) - то, есть завершение процесса, снятие блокировок со всей области файла(от 0 до бесконечности) работать не будет. В связи с этим, решили откатить данное изменения для CIFS и WINE и добавить в последний предупреждающие сообщения при наличии пересекающихся блокировок на чтение от одного пида на одном файловом дескрипторе и нескольких файловых дескрипторах одного файла. Собрал новую сборку 5.1.4 с учётом вышеописанного, исключив из неё патч fullmand (протестировал с помощью RECT и Connectathon test suite).
(В ответ на comment #15) > Создал и протестировал три патча, исправляющие вышеуказанные недостатки. > Отправил в рассылку. Последний из трёх патчей принят в аптрим. Переосмыслил первый, разбил второй на два и отправил в рассылку три новых патча.
(В ответ на comment #19) > Переосмыслил первый, разбил второй на два и отправил в рассылку три новых > патча. Все три патча приняты в апстрим. Создал патч с подробными описаними 4-х основных реализованных функий (test и add/set для mandatory и posix вариантов), логика работы которых нуждается в описании.
(В ответ на comment #20) > Создал патч с подробными описаними 4-х основных реализованных функий (test и > add/set для mandatory и posix вариантов), логика работы которых нуждается в > описании. Патч в апстрим.
(В ответ на comment #18) > Собрал новую сборку 5.1.4 с учётом вышеописанного, исключив из неё патч > fullmand (протестировал с помощью RECT и Connectathon test suite). Тестирование сборки 5.1.4 прошло успешно: http://bugs.etersoft.ru/show_bug.cgi?id=7685#c23. Данный код войдёт в следующий релиз 5.2.0. Задача решена.
> В связи с этим, решили откатить данное изменения для CIFS и WINE и добавить в > последний предупреждающие сообщения при наличии пересекающихся блокировок на > чтение от одного пида на одном файловом дескрипторе и нескольких файловых > дескрипторах одного файла. Изменение убрал. Предупреждение пока не добавлял. Не очень понятно, относится оно только к CIFS или к остальным ФС тоже. Какая проблема возникает при установке пересекающихся блокировок на чтение?
(В ответ на comment #23) > Изменение убрал. Предупреждение пока не добавлял. Не очень понятно, относится > оно только к CIFS или к остальным ФС тоже. Какая проблема возникает при > установке пересекающихся блокировок на чтение? При наличии пересекающихся блокировок в связке CIFS+WINE возникают проблемы, связанные с тем, что CIFS не позволяет разбивать существующую блокировку. То есть вариант для POSIX файловых систем, когда у нас стоят блокировки (0,10) и (5,15), и мы, чтобы снять только первую, отправляем запрос снять (0,5), для CIFS не проходит из-за ограничений протокола. Исправить это, не сломав принципы функционирования VFS, пока непонятно как. Поэтому, предлагаю в случае наличия пересекающихся блокировок от одного процесса (пусть и с нескольких файловых дескрипторов) выводить предупреждающее сообщение в случае CIFS.
Не очень понял, чем закончилось. Мы добавили предупреждение при пересекающихся блокировках?
Да, добавили.
(В ответ на comment #24) ... > есть вариант для POSIX файловых систем, когда у нас стоят блокировки (0,10) и > (5,15), и мы, чтобы снять только первую, отправляем запрос снять (0,5), для > CIFS не проходит из-за ограничений протокола. > > Исправить это, не сломав принципы функционирования VFS, пока непонятно как. А нельзя снимать блокировку и ставить новую? Или ставить новую и снимать старую? Возможно это стоит обсудить. Как-то же должна решаться задача совместимости с POSIX. С другой стороны, если это Wine написан так, что использует подход разбиения блокировки, быть может стоит его код пересмотреть?
(В ответ на comment #27) > (В ответ на comment #24) > ... > > есть вариант для POSIX файловых систем, когда у нас стоят блокировки (0,10) и > > (5,15), и мы, чтобы снять только первую, отправляем запрос снять (0,5), для > > CIFS не проходит из-за ограничений протокола. > > > > Исправить это, не сломав принципы функционирования VFS, пока непонятно как. > А нельзя снимать блокировку и ставить новую? Или ставить новую и снимать > старую? > Возможно это стоит обсудить. Как-то же должна решаться задача совместимости с > POSIX. Это будет неатомарно, поэтому смысла особого нет. > > С другой стороны, если это Wine написан так, что использует подход разбиения > блокировки, быть может стоит его код пересмотреть? Wine написан основываясь на принципах функционирования VFS. Правильнее сделать так, как уже обсуждалось ранее: добавить в VFS специальный под-вызов FCNTL, который будет обрабатывать логику работы блокировок в стиле Windows. Но это отдельная большая задача.
