Помимо того, как наши патчи требуют анализа с кого-то другого, чтобы быть принятыми, так и от нас желательно участвовать в анализе сторонних патчей. Это поможет нам изначально повлиять на изменение интересующих нас мест кода и заручиться поддержкой других разработчиков при продвижении своих патчей.
Провёл анализ патчей направленных на исправлении логики состояния соединения 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
http://permalink.gmane.org/gmane.linux.kernel.cifs/2204
Не проставилось время в посте выше.
http://comments.gmane.org/gmane.linux.kernel.cifs/2206
Провёл анализ данного патча - добавление параметра пространства имён сети при установке соединения. 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 дней.
