Bug 4290

Summary: Проблемы с блокировками в новых версиях Wine
Product: WINE@Etersoft Reporter: Евгений Синельников <sin>
Component: Файловые операцииAssignee: Александр Морозов <amorozov>
Status: CLOSED FIXED QA Contact: Денис Баранов <baraka>
Severity: critical    
Priority: P1 CC: avk, justsoul, kondratyuk, lav
Version: 1.0.10   
Target Milestone: release 1.0.11   
Hardware: PC   
OS: All   
Whiteboard:
Заявки RT: http://rt.etersoft.ru/Ticket/Display.html?id=11127 Связано с:
Дата напоминания:
Bug Depends on:    
Bug Blocks: 3043, 3044, 3932    

Description Евгений Синельников 2009-09-11 14:38:06 MSD
По мотивам вчерашнего общения с ООО "ЛЭПКОС", подтвердилась проблема, которая показывает регрессию при работе с блокировками в новых версиях 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. Давайте смотреть, как менялся код для блокировок.
Comment 1 Александр Морозов 2009-09-11 17:46:38 MSD
Да, проблема с блокировками есть. При совместной работе 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).
Comment 2 Vitaly Lipatov 2009-09-11 18:37:48 MSD
(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 не показывает проблему, надо понять, что в нём усовершенствовать.

Comment 3 Александр Морозов 2009-09-14 14:10:45 MSD
Проблема не воспроизводится с 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). По-видимому, проблема только на новых ядрах.
Comment 4 Александр Морозов 2009-09-14 14:56:45 MSD
На 2.6.30-std-def-alt10 сбрасывается блокировка после закрытия файлового дескриптора. Сделал тестовую программу для воспроизведения проблемы: wine-etersoft-devel/cifs/lincifs
Comment 5 Евгений Синельников 2009-09-14 15:04:29 MSD
(In reply to comment #4)
> На 2.6.30-std-def-alt10 сбрасывается блокировка
> после закрытия файлового дескриптора.
> Сделал тестовую программу для
> воспроизведения проблемы:
> wine-etersoft-devel/cifs/lincifs
> 

Ну, так это верно, если сервер - Samba. Тут нужно отключать unix расширения, чтобы на самбе это перестало работать...

Патч для сбрасывания блокировок после закрытия файлового дескриптора на CIFS, который убрали, исходно был для Windows-сервера, который не умеет unix-extensions.
Comment 6 Александр Морозов 2009-09-14 15:22:22 MSD
> Ну, так это верно, если сервер - Samba.

Но WINE при таком поведении блокировок корректно работать не сможет.
Comment 7 Александр Морозов 2009-09-14 15:27:10 MSD
> Ну, так это верно, если сервер - Samba.

Насколько я понимаю, samba монтируется с -t smbfs, а в данном случае всё-таки -t cifs.
Comment 8 Евгений Синельников 2009-09-14 16:33:06 MSD
(In reply to comment #7)
> > Ну, так это верно, если сервер - Samba.
> 
> Насколько я понимаю, samba монтируется с -t smbfs,
> а в данном случае всё-таки -t cifs.
> 

Вы неправильно понимаете. Samba как раз и работает по протоколу CIFS. А то, что раньше драйвер в ядре назывался smbfs, для ранних версий протокола, здесь уже не важно.
Comment 9 Александр Морозов 2009-09-14 17:00:44 MSD
> Ну, так это верно, если сервер - Samba. Тут
> нужно отключать unix расширения, чтобы на
> самбе это перестало работать...

С отключенными unix extensions блокировка при закрытии дескриптора не сбрасывается. Мониторы пользователей в 1С 7.7 работают нормально.

А у нас в документации где-нибудь про unix extensions написано?
Comment 10 Евгений Синельников 2009-09-14 20:47:13 MSD
Когда я узнал, что нужно оторвать POSIX поведение, которого мы ранее отдельно добивались, я уже полагал, что придётся отключать unix-extensions и думал, что при таком требовании те, кто внесут соответствующие изменения внесут поправку в документацию.

Но теперь я так понимаю, что новый etercifs должен был не просто отключить исправления, но и автоматом выставить отключение unix-extensions.

Вообще, это не хорошо, потому что без unix-extensions не будут работать символические ссылки и другие unix-штуки. Плохо тут ещё и то, что это опция включается глобально - не может быть выставлена для отдельных шар.
Comment 11 Александр Морозов 2009-09-14 21:03:16 MSD
> Вообще, это не хорошо, потому что без
> unix-extensions не будут работать символические
> ссылки и другие unix-штуки. Плохо тут ещё и то,
> что это опция включается глобально - не
> может быть выставлена для отдельных шар.

А можно ли сделать так, чтобы сброс блокировок при закрытии не производился только для тех файлов, которые открыты с опциями, передающими флаги вроде SHARE_READ, и чтобы это делалось независимо от unix extensions?
Comment 12 Vitaly Lipatov 2009-09-14 21:11:32 MSD
(In reply to comment #10)
> Когда я узнал, что нужно оторвать POSIX
> поведение, которого мы ранее отдельно
> добивались, я уже полагал, что придётся
> отключать unix-extensions и думал, что при таком
> требовании те, кто внесут соответствующие
> изменения внесут поправку в документацию.
Не вижу никакой связи между нашим патчем на POSIX-поведение и работой Unix-extensions на сервере. Если ты видел какие-то последствия отмены этого патча, можно было о них сообщить.
Comment 13 Александр Морозов 2009-09-14 21:22:44 MSD
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 при этом отключены).
Comment 14 Евгений Синельников 2009-09-14 21:28:12 MSD
(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?
Comment 15 Vitaly Lipatov 2009-09-14 23:29:26 MSD
(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.

Comment 16 Александр Морозов 2009-09-15 12:02:18 MSD
Кстати, хочу обратить внимание на то, что по крайней мере на ядрах 2.6.27 и 2.6.28 блокировки не сбрасываются и при включенных unix extensions.
Comment 17 Александр Морозов 2009-09-15 12:25:50 MSD
> Вообще это какое-то странное предложение.

Просто это меньшее отклонение от POSIX, чем просто запрет на сброс блокировок во всех случаях.

> Я так понимаю, что новый Wine требует
> отключения unix-extesions вот и всё...

Вроде бы в отношении CIFS в WINE ничего принципиально в последнее время не менялось.

> Вообще я не могу отслеживать
> эту часть, поскольку технические детали
> развития wine особо не обсуждаются... Выбор
> этого технического решения на обсуждение
> не выносился... 

http://bugs.etersoft.ru/show_bug.cgi?id=4132
Comment 18 Alexey 2009-09-15 18:05:38 MSD
Мы проверили работу последней сборки (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 ядром (которых у нас большинство), и, соответственно, типовой наш самба-сервер, для тестирования.

С уважением,
Алексей (ЛЭПКОС)
Comment 19 Oleg Volkov 2009-09-15 18:42:47 MSD
(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 уважением,
Олег Волков (Лэпкос)