Summary: | VVS зависает, если база находится на Windows-сервере | ||
---|---|---|---|
Product: | CIFS@Etersoft | Reporter: | Александр Морозов <amorozov> |
Component: | блокировки файлов и доступ | Assignee: | Pavel Shilovsky <piastry> |
Status: | CLOSED FIXED | QA Contact: | Денис Баранов <baraka> |
Severity: | normal | ||
Priority: | P3 | CC: | kipruss, lav, sin |
Version: | не указана | ||
Target Milestone: | --- | ||
Hardware: | PC | ||
OS: | Linux | ||
Whiteboard: | |||
Заявки RT: | Связано с: | ||
Дата напоминания: | |||
Bug Depends on: | |||
Bug Blocks: | 3043, 4284, 5203 |
Description
Александр Морозов
2010-03-03 19:19:42 MSK
База VVS есть на //winxp/winxp_share: в vvs находится сама база, в vvs_net - сетевые файлы Paradox. Протестировал с помощью lincifs2.c Результаты следующие: 1. Linux сервер forcemand,direct F_SETLK F_WRLCK 0: 0 read: -1 (errno 13) wine F_SETLK F_WRLCK 0: 0 read: 14 (errno 0) 2. Windows сервер direct F_SETLK F_WRLCK 0: 0 read: -1 (errno 13) wine F_SETLK F_WRLCK 0: 0 read: 14 (errno 0) Результаты оправдывают ожидания: параметр wine включает режим работы wine и чтение работает. Так надо заметить, что параметр direct не менял результатов тестирования. У меня с сервером на WinXP вывод такой: F_SETLK F_WRLCK 0: 0 read: -1 (errno 11) Клиент atlant (2.6.30-std-def-alt15), etercifs-4.4.5-alt1. mount -o user=guest,pass=,rw,iocharset=utf8,noperm,wine //winxp/winxp_share /mnt/winxp Выяснил проблему - до версии ядра 2.6.30 включительно cifs при монтировании Windows сервера или Linux сервера + nounix выставлял на файлы биты доступа таким образом, что включались mandatory блокировки внутри VFS, которая сама их разруливала. Потому хаки с параметром wine не работали - во время чтения/записи VFS сама проверяла mandatory блокировки и возвращала -EAGAIN. С 31 ядра же в cifs перестали выставлять биты доступа к файлу на mandatory блокировки и потому у меня тест проходил. Теперь надо протестировать VVS на 31 или 32 ядре с параметром wine. (In reply to comment #4) > Выяснил проблему - до версии ядра 2.6.30 Стоит нам делать таблицу с версиями etercifs и версиями ядер, указывая состояние, и явно отмечая неработающие комбинации? Так будет проще признавать версии устаревшими. > включительно cifs при монтировании Windows > сервера или Linux сервера + nounix выставлял на > файлы биты доступа таким образом, что А что за биты доступа? ... Про табличку - хорошая идея. Про биты: если установлен s-бит на группе и нет бита на выполнения группе, то это расценивается как режим mandatory блокировок на файле. Собственно вот строчка в cifs до 30 ядра влючительно: vol->file_mode = (S_IRWXUGO | S_ISGID) & (~S_IXGRP); а вот - начиная с 31 ядра: vol->dir_mode = vol->file_mode = S_IRUGO | S_IXUGO | S_IWUSR; (In reply to comment #6) > Про табличку - хорошая идея. Будем делать: http://bugs.etersoft.ru/show_bug.cgi?id=5184 > Про биты: если установлен s-бит на группе и > нет бита на выполнения группе, то это > расценивается как режим mandatory блокировок > на файле. А, понял. > Теперь надо протестировать VVS на 31 или 32
> ядре с параметром wine.
На 2.6.32 (debian в VirtualBox) работает. Монтировал с noperm,wine и с noperm,wine,nounix.
Хорошо, буду портировать под все остальные ядра. Исправлено в 4.5.0-alt1. Принято. *** Bug 2639 has been marked as a duplicate of this bug. *** |