Bug 5572

Если NFS монтировать с параметрами soft,intr, то после таймаута соединение будет отваливаться и ошибка передаваться в программу с соответствующим результатом.

Тестировать ничего не надо. По умолчанию NFS бесконечно ждёт восстановления связи, поэтому при обращении к файлу возникает эффект «зависания».

Мы монтируем NFS с параметрами rw,soft,sync,intr,timeo=3,retrans=2
Пробовали также подключение с параметрами только rw,soft,intr

На NFS-сервере для экспорта файловых ресурсов используются ключи rw,root_squash,no_subtree_check,sync

В случае разрыва связи обращение на клиенте NFS к сетевым ресурсам NFS завершается с ошибкой.
1С при разрыве связи "зависает", не отвечает на команды, в том числе kill -9 pid_процесса_1C. При восстановлении работы сети 1С "отвисает" и продолжает работу. 

Мы считаем, что такое поведение вредит целостности данных в таблицах базы 1С.

Еще добавлю - операционная система OpenSuse 11.1
Просьба разобраться с вопросом. 

Отвисает она не всегда, а в некоторых случаях:
Если идет активная работа с файлами (запись/чтение) то не отвисает, а если пассивная (открыт журнал документов для просмотра) то чаще всего отвисает.

Уже не раз подобные проблемы приводили к потере данных в таблицах 1С.

(In reply to comment #2)
> Мы монтируем NFS с параметрами
> rw,soft,sync,intr,timeo=3,retrans=2
> Пробовали также подключение с параметрами
> только rw,soft,intr
Вообще мы столкнулись с тем, что NFSv4 ведёт себя
лучше в случае пропадания сервера или его перезагрузки.
http://bugs.etersoft.ru/show_bug.cgi?id=5447

> В случае разрыва связи обращение на
> клиенте NFS к сетевым ресурсам NFS
> завершается с ошибкой.
> 1С при разрыве связи "зависает", не отвечает
> на команды, в том числе kill -9 pid_процесса_1C.
Вы не могли бы приложить вывод $ strace -p pid_процесса_1C
в этом случае?

> При восстановлении работы сети 1С
> "отвисает" и продолжает работу. 
Это поведение противоречит параметрам intr,soft
 
Будем воспроизводить.

Created attachment 1699 [details]
Вывод команды strace -p pid_процесса_1С

Вот вывод команды strace до сосента отключения сетевого кабеля

... вывод команды strace до момента
отключения сетевого кабеля

Последний эксперимент был проведен на операционной системе OpenSuse 11.2
Поведение 1С аналогично предыдущим экспериментам с OpenSuse 11.1
 

Created attachment 1700 [details]
Вывод strace -p pid_процесса_1С на ALT Linux 4.1 Desktop

Это вывод strace -p pid_процесса_1С на ALT Linux 4.1 Desktop, версия Wine 1.0.11
При отключении кабеля 1С зависла (был открыт полный журнал документов). При включении кабеля, примерно через 10 секунд 1С отвисла, и продолжила работу в штатном режиме.

Мы можем предоставить вам копию нашей базы 1С, если это поможет разобраться с вопросом.

Насколько я понимаю, проблему следует сформулировать следующим образом:
При работе через NFS используется отложенная запись (кэширование на стороне клиента), что приводит к потере данных при разрыве соединения.

Тут важны следующие моменты:
1. За сколько времени до разрыва соединения производилась запись данных.
2. Насколько существенна реакция 1С на потерю связи  — ожидание возобновления связи, или выдача ошибки?

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

Мы думаем, что тут существенно именно то, что после восстановления связи до NFS-сервера 1С возобновляет работу с файлами как будто так и надо. При этом нарушается вся система блокировок файлов. Например, с другого компьютера можно войти монопольно. Т.е. клиент начинает работать с базой 1с несмотря на то что там уже кто то работает монопольно на момент востановления связи.

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

Протестировал на виртуальной машине:
смонтировал NFS-раздел с базой конфигурации.
запустил 1С, создал новый документ, провел его, отключил кабель, 1С ничего не выдало, просто висела, после подключения кабеля обратно работа без проблем возобновляется.

Монтировал: mount -t nfs -o rw,soft,nointr cellar:/var/local/share /mnt/nfs/

Экспериментировал с чтением с nfs-раздела.
Монтировал с параметрами rw,soft,intr.
Linux-программа, читающая с помощью pread, зависает на некоторое время в системном вызове, а затем тот завершается с ошибкой EIO. pread использовался, чтобы читать всё время с начала файла.
Win-программа зависает на ReadFile из-за того, что зависает read. Потом read возвращает EIO, и ReadFile возвращает ERROR_NOT_READY. Вызов CloseHandle также проходит довольно долго, так как подвисает wineserver: cначала на fstat, затем на close.

При монтировании с rw,soft,intr 1С при разрыве связи на самом деле не зависает намертво, а иногда выдаёт ошибки. То есть при таких параметрах монтирования зависания при работе с файлами по nfs не происходит, просто очень большой таймаут.

Created attachment 1710 [details]
1-я ошибка, которую вывела 1С при разрыве связи

Created attachment 1711 [details]
2-я ошибка, которую вывела 1С при разрыве связи

При монтировании с rw,soft,intr,timeo=1,retrans=1 ReadFile завершается сразу же, но на CloseHandle по-прежнему происходит зависание: fstat64 завершается сразу же, а вот close выполняется довольно долго. В случае с 1С при таких параметрах монтирования wineserver подвис на fcntl64, затем 1С вывела 2 сообщения об ошибках (см. скриншоты), потом окно 1С исчезло, wineserver подвис на close, далее процесс 1cv7s довольно долго что-то делал, я не дождался его завершения.

(In reply to comment #14)
> При монтировании с rw,soft,intr 1С при разрыве
> связи на самом деле не зависает намертво, а
> иногда выдаёт ошибки. То есть при таких
> параметрах монтирования зависания при
> работе с файлами по nfs не происходит, просто
> очень большой таймаут.
> 

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

Провёл ещё небольшой тест с UNIX-программой, читающей файл на NFS (rw,soft,intr,timeo=1,retrans=1). Если открыть файл на чтение-запись и установить блокировку на запись перед чтением, то при разрыве связи происходит длительное зависание на close. Блокировка после разрыва связи иногда сбрасывается, а иногда остаётся как будто навсегда. Если блокировку не ставить, то close завершается быстро. WINE, по-видимому, из-за блокировок и тормозит на close.

Сомневаюсь, что мы тут что-то можем изменить. Это подвисание - особенность NFS.

2 hunter.r:

И всё-таки, как воспроизвести ситуацию потери данных? Понятно, что если прервать связь в середине операции записи, то записываемые данные будут повреждены.

Мы пока не смогли понять, какое изменение вы от нас ждёте.

(In reply to comment #20)
> 2 hunter.r:
> 
> И всё-таки, как воспроизвести ситуацию
> потери данных? Понятно, что если прервать
> связь в середине операции записи, то
> записываемые данные будут повреждены.
> 
> Мы пока не смогли понять, какое изменение
> вы от нас ждёте.
> 

Вообще мы начали разбираться с этими вещами всвязи с тем, что после перехода с Windows на Linux+wine@Etersoft в наших магазинах часто происходят непонятные вещи. Привиду самые типичные примеры:

1. Пропадают документы за произвольную дату например чеки из журнала чеков. Например в день продажи чек точно был в журнале, а через 2-3 дня или другое время он пропадает. Персоналу магазина и системному администратору приходится разбираться, перепроводить документы. Рабочий процесс очень усложнился.

2. Если на компьютере с базой 1С запустить какой-то отчет (заведующий магазином), то на других компьютерах 1С начинает очень медленно работать.

Рассмотренная ситуация с обрывом связи похоже может и не является причиной таких ошибок. Так что мы не в претензиях.
Спасибо, что потратили время на разбирательство.

Закрываю, так как это особенность NFS, а не баг в WINE.

Закрываю