Bug 5181

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 находится на Windows-сервере, монтируется на Linux-машине с параметрами forcemand,direct. На Linux-машине под wine запускается VVS, при работе с базой он зависает на ReadFile. Проблема аналогична той, что была исправлена в 4077, только тогда речь шла о сервере на Linux.
Есть тест: wine-etersoft-devel/cifs/lincifs2.c
Comment 1 Александр Морозов 2010-03-03 19:29:28 MSK
База VVS есть на //winxp/winxp_share: в vvs находится сама база, в vvs_net - сетевые файлы Paradox.
Comment 2 Pavel Shilovsky 2010-03-03 20:23:44 MSK
Протестировал с помощью 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 не менял результатов тестирования.
Comment 3 Александр Морозов 2010-03-03 20:44:42 MSK
У меня с сервером на 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
Comment 4 Pavel Shilovsky 2010-03-04 00:31:42 MSK
Выяснил проблему - до версии ядра 2.6.30 включительно cifs при монтировании Windows сервера или Linux сервера + nounix выставлял на файлы биты доступа таким образом, что включались mandatory блокировки внутри VFS, которая сама их разруливала. Потому хаки с параметром wine не работали - во время чтения/записи VFS сама проверяла mandatory блокировки и возвращала -EAGAIN.

С 31 ядра же в cifs перестали выставлять биты доступа к файлу на mandatory блокировки и потому у меня тест проходил.

Теперь надо протестировать VVS на 31 или 32 ядре с параметром wine.
Comment 5 Vitaly Lipatov 2010-03-04 03:28:38 MSK
(In reply to comment #4)
> Выяснил проблему - до версии ядра 2.6.30
Стоит нам делать таблицу с версиями etercifs и версиями ядер, указывая состояние, и явно отмечая неработающие комбинации? Так будет проще признавать версии устаревшими.

> включительно cifs при монтировании Windows
> сервера или Linux сервера + nounix выставлял на
> файлы биты доступа таким образом, что
А что за биты доступа?
...
Comment 6 Pavel Shilovsky 2010-03-04 10:31:22 MSK
Про табличку - хорошая идея.

Про биты: если установлен 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;
Comment 7 Vitaly Lipatov 2010-03-04 11:34:58 MSK
(In reply to comment #6)
> Про табличку - хорошая идея.
Будем делать:
http://bugs.etersoft.ru/show_bug.cgi?id=5184

> Про биты: если установлен s-бит на группе и
> нет бита на выполнения группе, то это
> расценивается как режим mandatory блокировок
> на файле.
А, понял.

Comment 8 Александр Морозов 2010-03-05 17:58:30 MSK
> Теперь надо протестировать VVS на 31 или 32
> ядре с параметром wine.

На 2.6.32 (debian в VirtualBox) работает. Монтировал с noperm,wine и с noperm,wine,nounix.
Comment 9 Pavel Shilovsky 2010-03-05 18:12:50 MSK
Хорошо, буду портировать под все остальные ядра.
Comment 10 Pavel Shilovsky 2010-03-12 11:33:02 MSK
Исправлено в 4.5.0-alt1.
Comment 11 Денис Баранов 2010-03-14 19:52:25 MSK
Принято.
Comment 12 Pavel Shilovsky 2011-01-30 18:46:49 MSK
*** Bug 2639 has been marked as a duplicate of this bug. ***