| Summary: | Надо уйти от использования F_GETLK | ||
|---|---|---|---|
| Product: | WINE@Etersoft | Reporter: | Александр Морозов <amorozov> |
| Component: | Сетевые файловые системы | Assignee: | Александр Морозов <amorozov> |
| Status: | CLOSED FIXED | QA Contact: | Денис Баранов <baraka> |
| Severity: | normal | ||
| Priority: | P3 | CC: | lav, piastry |
| Version: | 1.0.12 | ||
| Target Milestone: | --- | ||
| Hardware: | PC | ||
| OS: | All | ||
| Whiteboard: | |||
| Заявки RT: | Связано с: | 6441 | |
| Дата напоминания: | |||
| Bug Depends on: | |||
| Bug Blocks: | 3043, 5991 | ||
|
Description
Александр Морозов
2010-10-21 14:46:29 MSD
Посмотрел, где используется F_GETLK. В закрытой части: в set_concurlock (проверка числа пользователей, работающих с одним файлом, лицензионное ограничение), в getc_lock. Эти функции используются при открытии файла. В открытой части: в set_unix_lock (установка блокировки), при работе с файлом /tmp/.wine-*/server-*/lock (думаю, это нам не интересно). 2 piastry@: что нам нужно оптимизировать: установку блокировки с помощью LockFile или открытие файла? Любое использование GET_LK при работе через CIFS порождает два запроса на сервер, потому от него надо уходить везде, где это возможно - то есть и при открытии, и при установке блокировки. Функция getc_lock проверяет наличие блокировки либо с помощью двух F_SETLK, либо с помощью F_GETLK. Так что с ней, видимо, ничего не сделаешь. Заметил, что в случае с NFS функция set_concurlock вызывается 2 раза для одного и того же файла. Переделал. Ещё одно изменение, касающееся на самом деле NFS, а не CIFS. Перенёс вызов release_lock в etersoft_sharing_post, где устанавливаются новые блокировки, ответственные за режим открытия файла. До этого мы могли сбросить блокировки, а новые не поставить (в случае выхода из check_sharing до вызова etersoft_sharing_post). Также сделал, чтобы release_lock использовала специально открытый для установки блокировок дескриптор. Сделал, чтобы в set_concurlock не использовалось F_GETLK (http://bugs.etersoft.ru/show_bug.cgi?id=6441). В set_unix_lock есть два места, в которых используется F_GETLK. В одно из них мы на CIFS не попадаем. В другое мы попадаем в случае файла, открытого только на чтение. Мне кажется, что установка блокировки на файл, открытый только на чтение - не очень частая ситуация. Она возникает в 1С7.7 при входе в некоторые базы (бутылка 1c77/1c77-scaner, конфигурация "Торговля+Склад") и при обновлении в мониторе пользователей. А для того, чтобы избежать использования F_GETLK в данном случае, придётся открывать дополнительный дескриптор, что не очень хорошо. Думаю, не стоит ничего делать с set_unix_lock, пока не выяснится, что это действительно узкое место. Принято. |