| Summary: | 1С 8.x: Совместная работа по CIFS | ||
|---|---|---|---|
| Product: | CIFS@Etersoft | Reporter: | Boris Savelev <boris> |
| Component: | блокировки файлов и доступ | Assignee: | Евгений Синельников <sin> |
| Status: | CLOSED INVALID | QA Contact: | |
| Severity: | blocker | ||
| Priority: | P1 | CC: | alexeev, baraka, boris, kipruss, kondratyuk, lav, lbeasty, leonid, pav, pv |
| Version: | не указана | ||
| Target Milestone: | --- | ||
| Hardware: | PC | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Заявки RT: | Связано с: | ||
| Дата напоминания: | |||
| Bug Depends on: | 2035, 2543, 2550, 2599, 2639, 2640 | ||
| Bug Blocks: | 1505, 1687, 2440, 3044, 3305 | ||
| Deadline: | 2008-11-07 | ||
|
Description
Boris Savelev
2008-02-14 12:10:33 MSK
надо ли проверить совместную работу 2х Linux-клиентов 1cv80/1cv81 по NFS/CIFS? (In reply to comment #1) > надо ли проверить совместную работу 2х > Linux-клиентов 1cv80/1cv81 по NFS/CIFS? > Думаю - да. Т.к. работа только одного Линукс клиента маловероятна. Не важно, 8.0 или 8.1. Главное не пытаться проверять смесь NFS/CIFS :) По сути от NFS проблем не ожидается (раз она поддерживает большие файлы, значит и большие блокировки тоже), CIFS же вообще не ясно как может не работать для 8.0, нужно смотреть что по тесту от двух пользователей получается. Заявка 3056 СРОЧНО!!! проверил под виндой с самба шарой cellar. все нормально. настроил 1c под своим аккаунтов в винде. пользователь boris пароль 111 Небольшой предварительный отчёт: ================================ На данный момент сделаны (на основе старых) два теста wintestwrite64 и lintestread64 (wine-etersoft-devel/samba). (для тестирования в обоих программах необходимо объявлять, одинаковые W_OFFSETxx). Если они корректны, то при помощи них обнаружено, что блокировка выше 2Gb не видна на cifs. хм... есть мнение, что этого быть не может, так как всё-таки 1cv80 работает... (Всё таки надо искать в районе oplock). Для этого нужно (будет) написать два теста (под win и lin), c задействованием oplock. я могу помочь чем-нибудь? По результатам тестирования обнаружен следующий требующий выяснения момент: в запросах на открытие файла, (в логах самбы) наблюдается следующий флаг: "access_mask". При запуске одной и той же программы из windows и linux, в логах самбы этот флаг разный. при запуске из под linux: access_mask = 0x120089. при запуске из под windows: access_mask = 0x20089. Теперь надо выяснить, что это за флаг такой... P.S. Тестировал с машин atlant и win2k. Запускал программу openfile из "wine-etersoft-devel/file". Некоторое дополнение: TЕсли просто запустить про-гу отдельно под win и отдельтно под lin, то: WIN: reply_ntcreate_and_X: flags = 0x16, access_mask = 0xa1 file_attributes = 0x0, share_access = 0x5, create_disposition = 0x1 create_options = 0x40 root_dir_fid = 0x0 LIN: reply_ntcreate_and_X: flags = 0x2, access_mask = 0x80000000 file_attributes = 0x80, share_access = 0x7, create_disposition = 0x1 create_options = 0x40 root_dir_fid = 0x0 После чего в логах самбы для lin-машины есть вызов: se_map_generic(): mapped mask 0x80000000 to 0x00120089 А в логах win-машины такого преобразования нет. Просьба прояснить параметры монтирования и состяние etercifs во время проблемных тестов. Дело в том, что на уровне блокировок наблюдается некоторое отличие в поведении модуля cifs в зависимости от того включены или нет LinuxExtensions. Хотелось бы уточнить зависит ли текущая проблема от состояния включенности LinuxExtensions. Напомню, что ранее LinuxExtensions использовался для отлкючения отправки авторизационной информации об идентификаторах, а также именах, пользователей и групп. Для включения аналогичного поведения при включенных LinuxExtensions, сетевой каталог необходимо монтировать с опцией noperm. В новых сборках мы планируем убрать отлкючение LinuxExtensions, потому хотелось бы проянснить потенциальные проблемы... Кроме того совершенно не ясно, как с этим обстоят дела сейчас и в каких режимах проводятся теущие тесты, для которых выявлены проблемы... Итак, я сегодня завёл 1C на двух машинах, и проверил подключение к пустой базе.... У меня получилось... Список активных пользователей показывает два компьютера... Может это не полноценная проверка, но уже что-то... Текущие параметры установки: - ALT Linux Sisyphus - 2.6.25-std-def-alt9 - 1Cv81-8.1.11.67-Windows-i386 - wine-1.0.9-alt24.i586.rpm - wine-etersoft-sql-1.0.9-alt5.i586.rpm - linux-cifs-3.2-alt1.src.rpm Теперь необходимо запустить это на рабочей базе... И сформировать набор эквивалентных тестов. Не знаю существенно ли это, но хочу записать, что при установке было замечено: а) При отсутствии пакета fonts-ttf-ms размер шрифта в инсталяторе выбирается неверно (слишком мелкий - еле разборчивый и мутный)... б) При выборе в winecfg версии Windows XP, для запуска инсталятора необходимо запускать winexp. Это странно, что обработчик запуска приложений не меняется сам, а также, что программа при этом валится... (In reply to comment #14) > Не знаю существенно ли это, но хочу > записать, что при установке было замечено: > а) При отсутствии пакета fonts-ttf-ms размер > шрифта в инсталяторе выбирается неверно > (слишком мелкий - еле разборчивый и > мутный)... Ну надо было в отдельную багу. Вообще надо сравнить с ситуацией при наличии fonts-ttf-liberation > б) При выборе в winecfg версии Windows XP, для > запуска инсталятора необходимо запускать > winexp. Это странно, что обработчик запуска > приложений не меняется сам, а также, что > программа при этом валится... Так устроен мир :) На всякий напомню, что проблемма зависит от последовательности запуска. Кто первее Lin или Win запускается... (см. начальный пост этого бага). (In reply to comment #16) > На всякий напомню, что проблемма зависит от > последовательности запуска. Спасибо... Действительно, я это упустил... Хотя доступно вроде написано... ;) Проверять такой вариант по-сложнее... Нужно где-то найти винду... В общем,тогда для полноты картины, не хватает варианта Windows after Windows... Это даст много полезных сведений... Думаю, что возможно проблема на самбе. Это будет очевидно, если проблема Windows after Windows тоже себя проявит на самбе, в то время как на винде такое решение, если я правильно всё понимаю, вполне себе работоспособно... Запустили на трех линукс-хостах и одной виндовс-виртуалке (WinXP). 1с - содержимое папки 1Cv81-8.1.11.67-Windows-i386 wine-1.0.9-alt24 libwine-1.0.9-alt24 linux-cifs-3.2-alt2 haspd-2.0-alt10 haspd-modules-2.0-alt10 wine-etersoft-sql-1.0.9-alt5 Видно сразу 4 активных пользователя. Вначале были сообщения о недоступности какого-то файла. При нажатии кнопки "перезагрузить" все было нормально. Если ещё появится эта ошибка - посмотрим подробнее. (In reply to comment #16) > На всякий напомню, что проблемма зависит от > последовательности запуска. > Кто первее Lin или Win запускается... > (см. начальный пост этого бага). > Сейчас позапускал с разной последовательностью. Ошибок не поймал. Возможно, из-за того, что Винда в виртуалке... Нам нужна база, потому что мы проверяем на пустой базе. *** Bug 2599 has been marked as a duplicate of this bug. *** Получил базу... на шаре с etercifs 1cv8.exe съедает 98% процессорного времени. Хотя, если перенести файлы на локальную ФС, всё запускается... Не могу понять из-за чего проблема, протестировать на обычном тоже cifs не удаётся из-за тогда, что WINE@Etersoft валится в assertion. Итого, для изучения проблемы хотелось бы оторвать проверку на драйвер. До проверки нескольких пользователей дело пока не дошло - есть ещё проблемы... Глупости, не надо открывать никакую проверку. Если ты хочешь убрать специфичные для etercifs изменения (кроме битов для open), ну так убери и сделай сборку без них. Насколько я понимаю, вопрос совместной работы на уровне запуска уже решён... Для этого необходимовключить LinuxExtensions... Сейчас, я полагаю, что etercifs уже не имеет к этому отношение, поскольку 1C способна запуститься и без использования Shared-flags. Какова же роль Shared-flags в других файловы операциях, в частности блокировках блоков файла, нужно ещё выяснять... Не ясным же остаётся и вопрос о том, какие блокировки на каких уровнях использует 1С... Пока я полагаю, что 1) 1С использует Shared-flags в так называемом монопольном режиме. Мною это пока не проверялось... Нужно будет проверить... 2) Во время совместной работы используются обычные файловые блокировки для разных частей базы, для чего Shared-flags не подходят, поскольку лочат файл целиком на стадии открытия... Получается, что Shared-flags нужны в исключительных случаях монопольного режима работы 1С. При использовании этого режима во время совместной работы других пользователей, может всплыть проблема с oplocks, которые должны корректно обрабатываться на клиентах... Из этого я делаю вывод, что текущая реализация драйвера, при отключении LinuxxExtensions, отрубает нормальное функционирование обычных файловых блокировок на блоках файла. С этим надо разбираться... Кроме того тесты показали, что полноценной поддержки Shared-flags в нашем cifs пока нет... Необходимо детально рассмотреть к каким следствиям приводит открытие файлов в режимах при работе с файлами... На стадии открытия, установка Shared-флагов из-под Linux, к адекватным последствиям не приводит... В большинстве варантоа, файлы пермещаются, удаляются, пишутся и читаются, при установке соотвественно O_DENYDELETE, O_DENWRITE и O_DENYREAD... (In reply to comment #0) > с 1cv77 все нормально. > Проявляется так: > SAMBA-share: > Linux alone - OK > Windows after Linux - OK > Linux after Windows - FAIL > Ошибка доступа к файлу "Z:\1c81base\1cv8.pfl" > Notepad: "Sharing violation" В 1с77, при такой последователности подключений к базе, ситуация аналогична 1с8.x: выводится "Ошибка при запуске журнала регистрации" Воспроизведено на mandriva 2009 + winXP, etercifs 3.6.1 и 3.7 Есть заявка по этой проблеме: http://rt.etersoft.ru/Ticket/Display.html?id=8762 ASP Linux 12 (ядро 2.6.23) ALT Linux 4.1 (2.6.25-std-def-alt10) База на линуксовой или виндовой шаре - не важно. Второго пользователя не пускает с ошибкой при запуске журнала регистрации. Если предварительно открыть журнал с помощью "tail -f", то не пускает уже первого пользователя. Воспроизведение - пока 100% А почему linux-eter cifs 1.54 под Mandriva 2008 снимает блокировки и 1сv77 работает. А linux-cifs-3.2 под Мандрива 2009 блокирует файлы 1с. Почему нельзя переписать cifs 1.54 под 2009. Там все работало. После установки cifs 1.54 делаю service linux-cifs build выдает ошибку . Напишу подробности в понедельник А почему linux-eter cifs 1.54 под Mandriva 2008 снимает блокировки и 1сv77 работает. А linux-cifs-3.2 под Мандрива 2009 блокирует файлы 1с. Почему нельзя переписать cifs 1.54 под 2009. Там все работало. После установки cifs 1.54 делаю service linux-cifs build выдает ошибку . Напишу подробности в понедельник Проблема начиная с комментария #25, была внесена в закрытой части сборка 11 и исправлена в eter12. P.S. Багу испортили комментариями совершенно по другой проблеме. Поскольку описанная проблемы с использованием etercifs потеряла актуальность, а сообщения >25 относятся к другой проблеме, мне здесь кажется интересным только сообщение http://bugs.etersoft.ru/show_bug.cgi?id=1153#c24 Думаю, багу стоит закрыть, а указанное сообщение не потерять, сославшись на него на странице Вики, где описываются и обсуждаются проблемы etercifs: http://wiki.office.etersoft.ru/testing/cifs/ - и далее по ссылкам. |