По мотивам вчерашнего общения с ООО "ЛЭПКОС", подтвердилась проблема, которая показывает регрессию при работе с блокировками в новых версиях wine (начиная с 1.0.10, как уверяет заказчик, но проверялось на 1.0.11). Проблема появлялась при обновлении со связки Cifs-4.2.1+Wine-1.0.9 на связку Cifs-4.3.8+Wine-1.0.11. В чём была проблема? В полной мере для меня это осталось не ясным. Реальную, повторяемую проверку делали только заказчики. У себя, вроде как, нам её не удалось пока воспроизвести... Кстати, я не совсем понимаю, как мы её воспроизводили, если никто точно не знал какой у заказчика дистрибутив и версия ядра? Там оказался Debian 5.0 и 4.0 с официальными версиями ядрами 2.6.18 и 2.6.26... У нас на стендах есть такие системы? Что выяснилось? Выяснилось, что ошибки возникали только при взаимодействии через CIFS, поэтому проблема предполагалась в нём, при этом ограничения сборки не давали возможности запустить "новый Wine на старом CIFS'е". На деле же, разница между 4.2.1 и 4.3.8 оказались не столь критичны. Для ядер версий выше 2.6.26 вообще косметические. Для рассматриваемых же ядер версий 2.6.18 и 2.6.26 откат существенных изменений, сделанных в 4.3.8, на прежний вариант из 4.2.1, не дал положительного эффекта в работоспособности Wine. При этом запуск Wine-1.0.9 на 4.3.8 оказался вполне успешным и предварительно проблем не показал. Из этого я делаю вывод, что в данном случае проблема именно в Wine. Давайте смотреть, как менялся код для блокировок.
Да, проблема с блокировками есть. При совместной работе 1С77 с atlant(2.6.30-std-def-alt10 + etercifs 4.3.8 + 1.0.11 sql eter8/eter3) и cellar(2.6.27-ovz-smp-alt7 + etercifs 4.3.8 + 1.0.11 sql eter8/eter3) пользователи не видят друг друга в мониторе пользователей (такая проблема уже была, см. баг 4118).
(In reply to comment #1) > Да, проблема с блокировками есть. При > совместной работе 1С77 с atlant(2.6.30-std-def-alt10 + > etercifs 4.3.8 + 1.0.11 sql eter8/eter3) и cellar(2.6.27-ovz-smp-alt7 + > etercifs 4.3.8 + 1.0.11 sql eter8/eter3) пользователи не > видят друг друга в мониторе пользователей > (такая проблема уже была, см. баг 4118). Желательно упростить условия, проверяя на одной машине, чтобы вывести из подозреваемых версию ядра (и etercifs соответственно). Если у нас воспроизводится, стоит проверить на 1.0.10, чтобы понять время внесения проблем. Поскольку winelocktest не показывает проблему, надо понять, что в нём усовершенствовать.
Проблема не воспроизводится с cellar (2.6.27-ovz-smp-alt7 + > etercifs 4.3.8 + 1.0.11 sql eter8/eter3) и lin-test (2.6.28-15-generic + etercifs 4.3.8 + 1.0.11 sql eter8/eter3). По-видимому, проблема только на новых ядрах.
На 2.6.30-std-def-alt10 сбрасывается блокировка после закрытия файлового дескриптора. Сделал тестовую программу для воспроизведения проблемы: wine-etersoft-devel/cifs/lincifs
(In reply to comment #4) > На 2.6.30-std-def-alt10 сбрасывается блокировка > после закрытия файлового дескриптора. > Сделал тестовую программу для > воспроизведения проблемы: > wine-etersoft-devel/cifs/lincifs > Ну, так это верно, если сервер - Samba. Тут нужно отключать unix расширения, чтобы на самбе это перестало работать... Патч для сбрасывания блокировок после закрытия файлового дескриптора на CIFS, который убрали, исходно был для Windows-сервера, который не умеет unix-extensions.
> Ну, так это верно, если сервер - Samba. Но WINE при таком поведении блокировок корректно работать не сможет.
> Ну, так это верно, если сервер - Samba. Насколько я понимаю, samba монтируется с -t smbfs, а в данном случае всё-таки -t cifs.
(In reply to comment #7) > > Ну, так это верно, если сервер - Samba. > > Насколько я понимаю, samba монтируется с -t smbfs, > а в данном случае всё-таки -t cifs. > Вы неправильно понимаете. Samba как раз и работает по протоколу CIFS. А то, что раньше драйвер в ядре назывался smbfs, для ранних версий протокола, здесь уже не важно.
> Ну, так это верно, если сервер - Samba. Тут > нужно отключать unix расширения, чтобы на > самбе это перестало работать... С отключенными unix extensions блокировка при закрытии дескриптора не сбрасывается. Мониторы пользователей в 1С 7.7 работают нормально. А у нас в документации где-нибудь про unix extensions написано?
Когда я узнал, что нужно оторвать POSIX поведение, которого мы ранее отдельно добивались, я уже полагал, что придётся отключать unix-extensions и думал, что при таком требовании те, кто внесут соответствующие изменения внесут поправку в документацию. Но теперь я так понимаю, что новый etercifs должен был не просто отключить исправления, но и автоматом выставить отключение unix-extensions. Вообще, это не хорошо, потому что без unix-extensions не будут работать символические ссылки и другие unix-штуки. Плохо тут ещё и то, что это опция включается глобально - не может быть выставлена для отдельных шар.
> Вообще, это не хорошо, потому что без > unix-extensions не будут работать символические > ссылки и другие unix-штуки. Плохо тут ещё и то, > что это опция включается глобально - не > может быть выставлена для отдельных шар. А можно ли сделать так, чтобы сброс блокировок при закрытии не производился только для тех файлов, которые открыты с опциями, передающими флаги вроде SHARE_READ, и чтобы это делалось независимо от unix extensions?
(In reply to comment #10) > Когда я узнал, что нужно оторвать POSIX > поведение, которого мы ранее отдельно > добивались, я уже полагал, что придётся > отключать unix-extensions и думал, что при таком > требовании те, кто внесут соответствующие > изменения внесут поправку в документацию. Не вижу никакой связи между нашим патчем на POSIX-поведение и работой Unix-extensions на сервере. Если ты видел какие-то последствия отмены этого патча, можно было о них сообщить.
1C 7.7, запущенные на atlant (2.6.30-std-def-alt10 + etercifs 4.3.8 + 1.0.11 sql eter8/eter3) и Debian 5.0.2 в VirtualBox (2.6.26-2-686 + etercifs 4.3.8 + 1.0.11 sql eter8/eter3), в мониторе пользователей друг друга видят (unix extensions при этом отключены).
(In reply to comment #11) > > Вообще, это не хорошо, потому что без > > unix-extensions не будут работать символические > > ссылки и другие unix-штуки. Плохо тут ещё и то, > > что это опция включается глобально - не > > может быть выставлена для отдельных шар. > > А можно ли сделать так, чтобы сброс > блокировок при закрытии не производился > только для тех файлов, которые открыты с > опциями, передающими флаги вроде SHARE_READ, и > чтобы это делалось независимо от unix extensions? > Принципиально такой костыль возможен, но технически, мне этот вариант совершенно не нравится. К тому же для этого необходимо патчить самбу. Вообще это какое-то странное предложение. Зачем делать такое труднопроверяемое решение? Это может вылезти боком в другом месте... Я так понимаю, что новый Wine требует отключения unix-extesions вот и всё... Это цена за новые фишки, которые получились в такой реализации... Вообще я не могу отслеживать эту часть, поскольку технические детали развития wine особо не обсуждаются... Выбор этого технического решения на обсуждение не выносился... Очень жаль, что мы нарвались на эту проблему в таком виде и я вовремя её не осознал, чтобы предупредить... Всё же было ясно... С другой стороны, куда смотрели разработчики и как прохлопали регрессию в релизе? (In reply to comment #12) > (In reply to comment #10) > > Когда я узнал, что нужно оторвать POSIX > > поведение, которого мы ранее отдельно > > добивались, я уже полагал, что придётся > > отключать unix-extensions и думал, что при таком > > требовании те, кто внесут соответствующие > > изменения внесут поправку в документацию. > Не вижу никакой связи между нашим патчем на > POSIX-поведение и работой Unix-extensions на сервере. > Если ты видел какие-то последствия отмены > этого патча, можно было о них сообщить. > А принципиальной связи и нет... и последствий я не видел... Я сетую на то, что не предупредил, что если закладываться на отсутствие сброса блокировок после закрытия файла, то этот патч оторвёт такое поведение только для Windows-шар, поскольку для Linux-шар - этим занимается самба... У меня вертелась идея спросить об этом, но сорвалась и я не смог её сразу сформулировать. Хотя вопрос остаётся прежним. Как быть с Linux-шарами, отключать unix-extesions?
(In reply to comment #14) ... > Принципиально такой костыль возможен, но > технически, мне этот вариант совершенно не > нравится. К тому же для этого необходимо > патчить самбу. Так делать не будем. ... > Я так понимаю, что новый Wine требует > отключения unix-extesions вот и всё... Это цена за Собственно, с чего мы начали 3 года назад. > новые фишки, которые получились в такой > реализации... Вообще я не могу отслеживать Какие фишки имеются в виду? > эту часть, поскольку технические детали > развития wine особо не обсуждаются... Выбор > этого технического решения на обсуждение > не выносился... Ну вы можете тут обсудить подробности решения конечно... Мне всегда казалось, что extensions - это расширения, а они оказываются меняют такую фундаментальную вещь, как сброс блокировок. Думаю, пока выхода, кроме nounix при монтировании, нет. По крайней мере пока мы не научимся получать текущий режим работы CIFS - с Unix extensions или без. ... > С другой стороны, куда смотрели > разработчики и как прохлопали регрессию в > релизе? Это вопрос о том, а как её можно заметить, эту регрессию? Уже есть понятный способ воспроизведения? > Я сетую на то, что > не предупредил, что если закладываться на > отсутствие сброса блокировок после > закрытия файла, то этот патч оторвёт такое > поведение только для Windows-шар, поскольку > для Linux-шар - этим занимается самба... Да, вот это конечно очень плохо. Нам и в голову не могло прийти, что для Linux они сделали по-другому. В общем эти Unix extensions - хак, который добавляет проблем, и непонятно зачем улучшает совместимость SAMBA с Linux, при том что SAMBA толком для Linux никогда не разрабатывалась. > сформулировать. Хотя вопрос остаётся > прежним. Как быть с Linux-шарами, отключать > unix-extesions? Это вопрос строки в документации и конфига etermount.
Кстати, хочу обратить внимание на то, что по крайней мере на ядрах 2.6.27 и 2.6.28 блокировки не сбрасываются и при включенных unix extensions.
> Вообще это какое-то странное предложение. Просто это меньшее отклонение от POSIX, чем просто запрет на сброс блокировок во всех случаях. > Я так понимаю, что новый Wine требует > отключения unix-extesions вот и всё... Вроде бы в отношении CIFS в WINE ничего принципиально в последнее время не менялось. > Вообще я не могу отслеживать > эту часть, поскольку технические детали > развития wine особо не обсуждаются... Выбор > этого технического решения на обсуждение > не выносился... http://bugs.etersoft.ru/show_bug.cgi?id=4132
Мы проверили работу последней сборки (WINE@Etersoft 1.0 SQL 1.0.11-eter8/3) c цифсом 4.3.8. Вне зависимости от параметра unix extensions вроде на первый взгляд работает (детально не тестировали, проверили только основную ошибку возникающюю при проведении). При этом, опять-же вне зависимости от данного флага, предыдущая сборка даёт повторяемость ошибки. Проверка делалась на 26 ядре из репозитория Деб5. > По крайней мере пока мы не научимся > получать текущий режим работы CIFS - с Unix > extensions или без. Мгм. Конечно, это дело разработчиков, но к примеру у нас активно используется шара, на которой фактически хранится большая часть информации пользователей, и которая при отключенных extensions м-м-м мягко говоря работает далеко не так как надо. Т.о. получается, что Вы таким образом поставите перед выбором - либо непонятки с 1С, либо непонятки с другими шарами? Повторю своё предложение собрать Вам VM-машину - нашего типового клиента, ну, скажем, с нашим типовым 18 ядром (которых у нас большинство), и, соответственно, типовой наш самба-сервер, для тестирования. С уважением, Алексей (ЛЭПКОС)
(In reply to comment #18) > Мы проверили работу последней сборки > (WINE@Etersoft 1.0 SQL 1.0.11-eter8/3) c цифсом 4.3.8. Вне > зависимости от параметра unix extensions ... А соответственно и независимо от nounix - параметра монтирования шары (Возможно, что дальнейшее не в эту тему) Так же в ходе тестирования обнаружился следующий баг: При использовании параметра direct при монтировании шары перестает сохранять документы опенофис (3.1.1), выдавая "Невозможно создать резервную копию". Есть ещё баги с корзиной KDE при удалении с шары и с возникающими файлами типа "cifs####"(Вообще призрачно). C уважением, Олег Волков (Лэпкос)
