Bug 3725

Баг состоит, скорей всего, в том, что кеш файлов не обновляется с сервера и соотвествено 1с пишет в файлы на основе устаревших данных.
Диагностируется легко. Открываем на двух машинах в 1с один и тот же журнал документов. Создаем и записываем на одной из них новый документ.
На другой будет следующее
Если стоит etercifs 4.1.х (ну или виндовая машина), то через пару секунд документ появится в журнале.
На etercifs 4.2.х документ не появляется.

Все из-за того, что при переходе на 4.2.0 были убраны ваши оплоковские патчи. Можно узнать почему они были убраны? Может надо вине новый какой? (сейчас 42).

Прокоментируйте как нибудь, пожалуйста.

Нужно уточнить условия (параметры монтирования, дистрибутив клиента, версия ядра, версия настройки самбы на сервер), чтобы повторить эту проблему...

2lbeasty: Покрывают ли текущие тесты эту проблему?

(In reply to comment #1)
> Все из-за того, что при переходе на 4.2.0 были
> убраны ваши оплоковские патчи. Можно
> узнать почему они были убраны? Может надо
> вине новый какой? (сейчас 42).
> 
> Прокоментируйте как нибудь, пожалуйста.
> 

Оплоковские патчи были убраны только в ядрах 2.6.27 и 2.6.28 по той причине, что в ядре дописали код, касающийся SMB flush, который должен был решать проблемы, до этого решаемые оплоковскими патчами.

Вот коммит из апстрима:

http://git.kernel.org/?p=linux/kernel/git/sfrench/cifs-2.6.git;a=commit;h=912671e6bcf007104dafef763bd01648a4c99655

Вот наши изменения

http://git.etersoft.ru/people/kipruss/packages/?p=etercifs.git;a=commit;h=7c5e869153b3dadf8cb96fb5eccc2f6b419f9c9c

в любом случае, если проблема есть, нужно её повторить. Для этого нужно точно знать условия... Уточните, пожалуйста следующие параметры:
- опции монтирования;
- дистрибутив клиента;
- версия ядра клиента;
- версия и настройки самбы на сервере.

Без этих параметров вести речь о работоспособности той или иной версии etercifs довольно проблематично.

(In reply to comment #2)
> Нужно уточнить условия (параметры
> монтирования, дистрибутив клиента, версия
> ядра, версия настройки самбы на сервер),
> чтобы повторить эту проблему...

Сервера и клиенты -- Ubuntu 8.10
wine@etersoft network 42/17
Самба на сервере настроена по умолчанию. Шара:
[Basa]
    path = /var/Basa
    public =yes
    writable = yes
    directory mask = 777
    create mask = 666
    guest ok = yes
    force user = denis
Монтируем с iocharset=utf8,forcemand,rw,noperm

А причем здесь SMB flush и ваш патч? В одном случае запись буферов, а в другом принудительное обновление кеша.

Возвращайте взад. Хотя жаль, скорость в совместном режиме крутая стала...

да, забыл, ядро 2.6.27-11

В-общем, так. Если не будет возражений, то в версию 4.3.0 верну наши оплоки для 27 и 28 ядра. А потом разберёмся.

А может допилите их слега, а? Почему он по mtime inode с сервера не обновляет?

Существует предположение, что использование опции монтирования direct (или forcedirectio, что то же самое) даёт тот же эффект, что и наши патчи.

2 отдел тестирования: Можно ли это проверить? Мы в свою очередь проверим тестами.

(In reply to comment #9)
> 2 отдел тестирования: Можно ли это
> проверить? Мы в свою очередь проверим
> тестами.
> 

То есть идеальный вариант - 
1. Используя версию 4.2.1 воспроизвести эту багу
2. Поставить опцию монтирования direct и НЕ воспроизвести!

(In reply to comment #9)
> Мы в свою очередь проверим
> тестами.
> 


Проверили. Работает. С опцией direct тесты на оплоки не отваливаются.

Да, с forcedirectio журнал документов обновляется нормально.
Но как тогда с производительностью? Мне кажется корень 3032 баги тут зарыт.

(In reply to comment #12)
> Да, с forcedirectio журнал документов обновляется
> нормально.
> Но как тогда с производительностью? Мне
> кажется корень 3032 баги тут зарыт.
> 

Нашёл свой косяк: при отрывании нашего патча с оплоками забыл удалить пару строк. Исправлю в 4.3.0. Возможно, что всё будет нормально и без direct.

ядро 2.6.27-ovz-smp-alt1.1
wine 1.0.10 сборки 15/10
etercifs-4.2.1-alt1.testing2

БЕЗ! опции монтирования direct в 1с77 всё ок.
Одновременное создание, проведение/сохранение документов работает. Обновление списка документов при этом у обоих пользователей происходило корректно.

А можно узнать версию и настройки самбы?
А также проверить wine 1.0.9?
Вы же 1.0.10 еще не зарелизили.

выпущен 4.3.0.
см. http://bugs.etersoft.ru/show_bug.cgi?id=3755#c1
Убрал свой недочет в ядре 2.6.27, так что надо смотреть.
Попросил Юру собрать для Убунту.

(In reply to comment #15)
> А можно узнать версию и настройки самбы?

rpm -qa |grep samba
samba-client-control-1.2-alt1
samba-common-3.0.31-alt1
samba-client-3.0.31-alt1
samba-3.0.31-alt1

Монтировал с опциями forcemand,noperm

конфиг стандартный, на бузу такой же как у вас.

> А также проверить wine 1.0.9?
> Вы же 1.0.10 еще не зарелизили.
> 
Сейчас мы работаем с 1.0.10 - предлагаю, перейти на бету - она уже вполне стабильная. Да и до релиза осталось немного.

(In reply to comment #16)
> Попросил Юру собрать для Убунту.
> 
Вот пакет под Убунту: ftp://ftp.etersoft.ru/pub/Etersoft/CIFS@Etersoft/4.3.0/Ubuntu/8.10/etercifs_4.3.0-eter1ubuntu_all.deb

У меня самба 3.2.3
Пакет видел. Спасибо, попробую сегодня или завтра сутра.

Попробовал 4.3 -- не помогло. Но нашел прикольную зависимость.
Если сколько угодно ждать -- документ не появляется в журнале на машине с cifs>=4.2, но если на этой машине выполнить команду ls -l /каталог/с/базой -- то документ появляется в течении секунды (стандарного времени опроса для 1с).

(In reply to comment #20)
> Попробовал 4.3 -- не помогло.

Всмысле не помогло - без параметра монтирования direct надо полагать? Потому что выше вы подтверждали, что direct заменяет хак с оплоками.

А дальше - чтобы сделать правильно и быстро - надо смотреть...

(In reply to comment #21)
> Всмысле не помогло - без параметра
> монтирования direct надо полагать? 

Да, конечно, без него.
Ставлю 1.0.10 -- буду тестировать.

На 1.0.10 без direct проблема не исчезает.

Первоначальная постановка вопроса себя исчерпала. В 4.3.0 исправлены баги в коде и, хотя я не вернул наши патчи с оплоками, но нашёлся параметр монтирования direct, который эти патчи заменяет. Остается добиваться повышения производительности. Багу переименовываю и перевешиваю.

Написал патч, должно решить проблемы без опции direct при этом сохранив приличную скорость работы.

http://git.etersoft.ru/people/piastry/packages/?p=cifs-2.6.git;a=commitdiff;h=4a40914327258de9178feb3dda6c4ef60c0af3b5

(In reply to comment #25)
> Написал патч, должно решить проблемы без
> опции direct при этом сохранив приличную
> скорость работы.
> 
> http://git.etersoft.ru/people/piastry/packages/?p=cifs-2.6.git;a=commitdiff;h=4a40914327258de9178feb3dda6c4ef60c0af3b5
> 

Приложил этот патч в версию 4.3.1 во все ядра - ftp://ftp.etersoft.ru/pub/Etersoft/LINUX@Etersoft/Boxes/etercifs/noarch/RPMS.default/etercifs-4.3.1-alt1.noarch.rpm
Заодно оторвал наш патч с оплоками отовсюду, откуда ещё не убирал. Заменять параметром монтирования direct. Если что не работает - чинить. С оплоками все равно было плохо.

> Заменять параметром монтирования direct.С оплоками все равно было
> плохо.

Да, согласен. Сегодня потестировал 4.3.0 с forcedirectio на рабочей базе -- скорость меньше чем у клиента с windows me процентов на 20. Но это все равно гораздо лучше чем было. Буду пробовать внедрять.
Так же решилась проблема с долгим ожиданием окна ввода пароля при запуске (см. мой истеричный пост в баге 2915).

Наверное можно прикрывать багу.

(In reply to comment #28)
> Наверное можно прикрывать багу.
> 

Да, кстати. ftp://ftp.etersoft.ru/pub/Etersoft/CIFS@Etersoft/4.3.1/Ubuntu/8.10/etercifs_4.3.1-eter1ubuntu_all.deb

патч здесь предложеный уберите -- похоже именно из-за него 1с виснет при входе, если не стоит direct (возможно просто очень долго читает конфу -- я не дождался).

Да, согласен. Нашёл свою ошибку и исправил её. Изменения в гите - итого для этой баги надо брать два последних коммита из 

http://git.etersoft.ru/people/piastry/packages/?p=cifs-2.6.git;a=shortlog;h=refs/heads/v2.6.27-testing

Наверное то что вы сделали -- хорошо, завтра проверю. Но мне кажется, что тоже самое нужно сделать для do_sync_read, т.к. изменение именно этой функции привело к тому, что перестал обновляться журнал.

(In reply to comment #32)
> Наверное то что вы сделали -- хорошо, завтра
> проверю. Но мне кажется, что тоже самое
> нужно сделать для do_sync_read, т.к. изменение
> именно этой функции привело к тому, что
> перестал обновляться журнал.
> 

Нет необходимости, так как функция do_sync_read() вызывает внутри себя функцию через указатель aio_read, который указывает функцию из моего патча.

(In reply to comment #31)
> Да, согласен. Нашёл свою ошибку и исправил
> её. Изменения в гите - итого для этой баги
> надо брать два последних коммита из 
> 
> http://git.etersoft.ru/people/piastry/packages/?p=cifs-2.6.git;a=shortlog;h=refs/heads/v2.6.27-testing
> 

Пакет готов. Надеюсь, что в проживет чуть дольше двух предыдущих :)

ftp://ftp.etersoft.ru/pub/Etersoft/LINUX@Etersoft/Boxes/etercifs/noarch/RPMS.default/etercifs-4.3.2-alt1.noarch.rpm

Да, так все работает. Журнал документов отображается нормально и без direct. Однако, судя по всему оплоки никак не влияют на производительность 1с в разделенном режиме. По крайней мере мне не удалось найти ситуацию когда производительность без directio оказалась выше. Наверное это отражается на только монопольном.
В любом случае багу можно прикрывать.

(In reply to comment #35)
> Да, так все работает. Журнал документов
> отображается нормально и без direct. Однако,
> судя по всему оплоки никак не влияют на
Безусловно, оплоки при разделении файлов в режиме R/W никак не используются,
поскольку представляют собой локальное кэширование на чтение/запись, что недопустимо.

Блин! Люди! Издеваетесь?
Сегодня опять убил индексы на рабочей базе, из-за того, что в 4.3.6 (может раньше, но в 4.3.2 было) убрали патч cif_aio_read!

Разобрался. Почитал 3807. Пожалуйста сообщите в рассылку для клиентов, когда можно будет убрать direct

Конечно сообщим. Рад, что нормальная работа etercifs 4.3.6 подтвердилась.
Для истории записываю, что обязательно монтирование с параметрами
forcemand,direct