| Summary: | Анализ патчей в cifs-upstream | ||
|---|---|---|---|
| Product: | CIFS@Etersoft | Reporter: | Pavel Shilovsky <piastry> |
| Component: | Должностные | Assignee: | BUGS@Etersoft <bugs> |
| Status: | DEFERRED --- | QA Contact: | |
| Severity: | minor | ||
| Priority: | P4 | CC: | lav, sin |
| Version: | не указана | ||
| Target Milestone: | --- | ||
| Hardware: | PC | ||
| OS: | All | ||
| Whiteboard: | |||
| Заявки RT: | Связано с: | ||
| Дата напоминания: | onFridays | ||
|
Description
Pavel Shilovsky
2010-12-14 10:39:40 MSK
Провёл анализ патчей направленных на исправлении логики состояния соединения cifs клиента. Идея состоит в том, что клиент не будет устанавливать изначально забитые таймауты под конкретный запрос, а будет ждать ответ бесконечно и определять, что сервер недоступен по специальному "пинг" запросу каждые 30 секунд. Если сервер не отвечает на три запроса подряд, то мы считаем сервер недоступным и переустанавливаем соединение. Так же изменения коснулись стиля кода - много мест поправлено и исправлены потенциальные ошибки (например, добавлен повтор запроса на запись при ответе EAGAIN в момент флуша в синронном режиме. Один из вышеописанных патчей вызвал дискуссию на наличие races в кода удаления запросов из очереди. Выяснили, что на данный момент проблемы не существует, но существует возможность её появления в дальнейшем. Если есть возможность, и это не затруднительно, было бы хорошо видеть ссылки на коммиты. Да, конечно. Патч, описанный выше - https://patchwork.kernel.org/patch/398802/. Так же можно посмотреть остальные 13 патчей (правда после Jeff Layton добавил поддержку NT_CANCEL) и теперь это группа из 18 патчей. http://www.spinics.net/lists/linux-cifs/msg02082.html Провёл анализ новой версии патчей, относящихся к транспортному уровню. Начало по ссылке выше. Анализ нескольких патчей из вышеописанной группы (try #4): http://article.gmane.org/gmane.linux.kernel.cifs/2162 Не проставилось время в посте выше. Провёл анализ данного патча - добавление параметра пространства имён сети при установке соединения. https://patchwork.kernel.org/patch/472231/ Проблема описана вот тут: https://patchwork.kernel.org/patch/470221/ Синхронизировался с веткой master из апстрима. Провёл анализ патча: https://patchwork.kernel.org/patch/459311/ Провёл анализ патчей http://thread.gmane.org/gmane.linux.kernel.cifs/2308. Провёл анализ следующих патчей: https://patchwork.kernel.org/patch/512001/ (всё ок) https://patchwork.kernel.org/patch/512011/ (тут автор сам его отозвал, так что жду следующую версию) Провёл анализ и сделал замечания по патчу: https://patchwork.kernel.org/patch/639541/ Просмотрел серию патчей, добавляющих возможность асинхронной работы с записью. Ссылка на первый из них: https://patchwork.kernel.org/patch/683711/. (В ответ на comment #15) > Просмотрел серию патчей, добавляющих возможность асинхронной работы с записью. > Ссылка на первый из них: https://patchwork.kernel.org/patch/683711/. Так как данная серия очень важна с точки зрения производительности, я уделил её больше внимания: провёл подробный анализ патчей и протестировал. Выяснилось, что при работе с Windows 7 сервером на LAN при записи гигабайтного файла получается почти 20% пророст в скорости. Стоит заметить, что установка Windows 7 по умолчанию не смогла обработать такое количество одновременно приходящих запросов записи по CIFS. После исследования выяснилось, что данное поведение исправляет установка большего MaxWorkItems в регистре (я выставил 4096). Написал об этом в рассылку и так же приложил некоторые незначительные замечания по одному из патчей. Проанализировал и провёл тестирование второй версии патчей. Скорость увеличилась незначительно (около 0.5%), но возможно ситуация изменится при переходе от LAN к WAN. Провёл ревью третьей версии серии патчей для поддержки асинхронной записи. Начал тестирование четвёртой серии патчей для асинхронной записи. Ядро выдаёт kernel panic или зависает. После выяснилось, что проблема не в патчах, а в текущем master. Далее буду выяснять какой из патчей принёс ошибку. После исправленние вышеописанной ошибки, провёл тестирование серии патчей для асинхронной записи. Выявил увеличение производительности записи на ~15 процентов, по сравнению с последовательным вариантом. Провёл предварительный анализ двух серий патчей: 1) Реорганизация cifs_demultiplex_thread кода http://article.gmane.org/gmane.linux.kernel.cifs/4064 2) Добавление возможности асинхронного чтения http://article.gmane.org/gmane.linux.kernel.cifs/4082 Далее планирую изучить их более тщательно и провести тестирование (по второй серии как только выйдёт следующая версия - разработчик сам отозвал текущую). Провёл анализ и тестирование кода асинхронного чтения построенного поверх патчей реорганизации кода demultiplex_thread. Результаты для чтения на 100 Mbit LAN c сервером Windows 7 были близки к результатам для записи - около 11.5 MB/s против текущих 7 MB/s. Провёл анализ патча "Add support for flock over a cifs mount". Провёл анализ патча "cifs: lower default wsize when unix extensions are not used", который исправляет поведение записи на некоторых нестандартных CIFS серверах, выставив по умолчанию размер записываемых данных в одно сообщение 65536. Проанализоровал патч "RFC: Attach locks to cifsFileInfo instead of cifsInodeInfo", который решает проблему вызовы unlock: снимаются блокировки со всех файловых дескрипторов процесса, а не с дескриптора, вызвавшего unlock. Высказал свои замечания в рассылке. Провёл анализ серии из 8 патчей, конвертирующих работу записи в режимах direct и strictcache (без оплока на запись) в асинхронный режим. Провёл анализ серии из 4-х патчей: cifs: pave way for change to "strictcache" by default. Провёл анализ трёх патчей в рассылке. Изучал проблему (https://bugzilla.redhat.com/show_bug.cgi?id=867344) и соответствующие ей патчи в рассылке. Провёл анализ 6-и патчей в рассылке. Провёл анализ 4 патчей. Провёл анализ патчей в апстрим. Провёл анализ набора из 19 патчей, который улучшают алгоритм выбора параметров аутентификации и подписи. Провёл анализ 2 патчей. Провёл анализ патча "cifs: Allow mounts for paths for restricted intermediate paths", исправляющего монтирование путей с отсутствием прав доступа в середине. (В ответ на comment #35) > Провёл анализ патча "cifs: Allow mounts for paths for restricted > intermediate paths", исправляющего монтирование путей с отсутствием прав > доступа в середине. Протестировал патч, проблема не исправлена. Провёл анализ патча "[CIFS] Validate Negotiate Info". Провёл анализ патчей: [PATCH] cifs: use a flexarray in cifs_writedata [PATCH] cifs: clean up page array when uncached write send fails [PATCH] cifs: ensure that uncached writes handle unmapped areas correctly (см. http://bugs.etersoft.ru/show_bug.cgi?id=7142#c34) [PATCH] cifs: sanity check length of data to send before sending cifs: Wait for writebacks to complete before attempting write. Разбирался с проблемой (патчем) дэдлока в коде оплоков и ошибкой при использовании cache=loose. Откладываем задачи, к которым не обращались более 100 дней. |