Здесь планирую писать об участии в разработке CIFS при взаимодействии с остальными разработчиками.
На данный момент я хочу выделить следующие задачи: 1) Дальнейшая работа над транспортным уровнем модуля. Помимо, облагораживания кода, планируется выделить его в модуль cifs_common, для использования модулями cifs и smb2. 2) Анализ влияния smb2 leases на существующий код. В дальшейнем планируется выделить всю логику работы с айнодами и файловыми дескрипторами в cifs_common.
Хочу выделить ещё одну задачу. Функция cifs_open содержит совершенно ненужный вызов cifs_open_inode_helper, много дублирующего кода для posix и не-posix сценариев. Начал работать над этим.
В связи с проблемами по мотивам баги http://bugs.etersoft.ru/show_bug.cgi?id=6506 + отсутствием собранного пакета 2.6.37-rc1 в Fedora (чтобы избежать процесса cherry-pick патчей из ветки для тестирования в upstream) переехал на Ubuntu 10.04 пока на VirtualBox. Настроил систему, поставил нужное мне ядро, установил wine. Столкнулся с проблемой очень (!!!) медленной работы wine приложений в VirtualBox видимо из-за отсутствия у моего процессора поддержки виртуализации. Пока временно оставлю так (до решения баги 6506 и появления ядра 2.6.37-rc1 в Fedora). Если проблема не решится, то придётся ставить Ubuntu в качестве основной ОС. На данный момент планирую разобраться с предыдущим патчем (ip-port) - после тестирования там найден баг + продолжать пропихивать наши патчи non-direct режима в upstream, что пока идёт очень медленно.
Поправил патч ip-port (1), отправил его в рассылку.
Работал над функцией cifs_open. Убрал ненужную функцию cifs_open_inode_helper, выделил непосикс сценарий в отдельную функцию cifs_nt_create, сделал код cifs_open более общим для посикс и непосикс сценариев. Закоммитил код сюда: http://git.etersoft.ru/people/piastry/packages/?p=cifs-2.6.git;a=shortlog;h=refs/heads/mainline Планирую в этом репозитории держать последние актуальные коммиты по этой баге.
По транспотному уровню заменил union из sockaddr_in и sockaddr_in6 на sockaddr_storage, поправил код, на который это повлияло и немного поправил код своего патча. Пока не стал отправлять в рассылку, чтобы опять не появилась путаница с патчами.
Нечанно указал на час меньше в предыдущем посте.
Поправил cifs_open патч согласно комментариям их рассылки. Отправлять не стал по причине описанной выше. Хочу дождать комментариев в рассылке по политике отправки патчей. Обновил ветки helper-to-kernel и port-to-kernel на git.eter.
Провёл некоторую исследовательную работу. Выяснил, что часть кода smb2 клиента, относящаяся к установки соединения с сокетом сервера полностью копирует код cifs клиента. Имеет смысл пробросить дальше наш патч (port) пробросить в cifs_common модуль, чтобы избежать данной ошибки в дальнейшем на smb2. Что же касается наших патчей non-direct режима, то тут тоже можно выделить общую логику, но следует иметь ввиду, что в smb2.1 появились "лизы", о которых я писал выше. Потому как подзадачу ещё планирую выделить анализ влияния лизов на strict cache семантику. Итого имеем согласно приоритету следующие задачи для выполнения: 1) non-direct режим (бага 6227); 2) port и helper патчи; 3) Выделение socket connection логики в cifs_common модуль; 4) smb2.1 leases.
По мотивам этого поста http://bugs.etersoft.ru/show_bug.cgi?id=6517#c3 забрал компьютер у sin@. Планирую поставить на него Ubuntu и всё необходимое для тестирования wine на новых ядрах.
Поправил и отправил патчи helper и port. Патчи helper уже получили reviewed-by.
Отныне здесь буду лишь регистрировать текущие задачи по которым ведётся или планируется вестись работа. По каждой конкретной задаче планирую заводить отдельную багу, чтобы избежать путаницы.
Установил на офисный компьютер. Протянул сеть, установил Ubuntu 10.10, поставил и настроил необходимое для работы (в том числе и наши пакеты (wine, etercifs)). Проверил работоспособность.
Обновил бранч master на git.eter: http://git.etersoft.ru/people/piastry/packages/?p=cifs-2.6.git;a=summary
Вышел релиз v2.6.37 ядра. Обновил бранч на git.eter.
Обновил master и oplock-handling-to-kernel бранчи (смержив астрим) на git.eter. По цифс сейчас есть следующие задачи: 1) Выделение socket connection логики в cifs_common модуль; 2) Анализ smb2.1 leases для последующего выделения логики работы с файловыми дескрипторами и айнодами в cifs_common. В будущем хочется достичь следующего: вся общая логика работы модулей cifs и smb2 переедет в cifs_common, в модулях cifs и smb2 останутся только протоколо-специфичные части.
Написал в рассылку с предложением проверять валидность кеша каждый раз при чтении, так как сейчас уже есть опция, которая настраивает время "прокисания" кеша. Так уже делается сейчас в NFS. Данное предложение не касается режима strictcache, который работает с кешем намного строже. Буду ждать ответ.
Обсудил с lav@ дальнейшие работы по CIFS. Далее начну взаимодействовать с разработчиками апстрим по участию в работах над внедрению SMB2 в код CIFS. Так же надо будет упомянуть о баге про повторное монтирование ресурса (отсутствует проверка на пароль при попытке использовать существующее соединение).
Написал письмо, где рассказал о вышеописанной проблеме CIFS и про то, во что она превратится с приходом лизов (leases) из SMB2.1.
Получил ответ по поводу баги монтирования. Данная проблема известна и исправлена в 36 ядре. Что же касается SMB2, то были высказаны соображения по переходу на модель разделённого суперблока, который уже используется в NFS. Изучил немного данную модель - её использование действительно может быть оправданно.
Обсудил проблему валидации кэша при работе в non-strictcache режиме - буду готовить патч.
Синхронизировался с астримна git.eter: теперь актуальны master (для 39 ядра) и dev (для 40).
Синхронизировался с апстрим. Отписался по патчам - какие для 39 ядра, какие для 40.
Предложил реализацию организации структур обработки сообщений для cifs и smb2: http://permalink.gmane.org/gmane.linux.kernel.cifs/3073.
Написал свои соображения по поводу использования одной или различных структур сообщений для cifs и smb2. В любом случае, нам не избежать проверок вида: if (protocol_id == SMB2) smb2_func else cifs_func - поэтому нет смысла использовать одну общую структуру, которая вмещает в себя поля для cifs и smb2, тем самым попросту расходуя память. Конечно, таких структур будет одновременно в памяти не очень много, но всё же использование их мне кажется не оправданным. Так же высказал свои соображения, чтобы разделять сокет соединение для различных smb соединяний по разным протоколам (cifs и smb2), что позволит не держать открытым лишний сокет на клиенте.
Реализовал идею валидации кеша при чтении: http://git.etersoft.ru/people/piastry/packages/?p=cifs-2.6.git;a=commitdiff;h=514392920dcc2ff0fefbf6d6db784e7e393a957b Протестировал с помощью dbeanch с различными параметрами actimeo - наблюдал небольшое падение производительности, что и ожидалось. Далее буду продвигать этот патч в апстрим.
Создал ветку smb2-for-next и перенёс туда первые пять коммитов, которые нужно перенести из ветки for-2.6.40 (раньше в апстрим это был master, но потом пришлось перенести это в отдельную ветку, чтобы отдать в ядро срочные багфиксы для 2.6.39) для того, чтобы продолжить разработку smb2 с самой актуальной точки. http://git.etersoft.ru/people/piastry/packages/?p=cifs-2.6.git;a=shortlog;h=refs/heads/smb2-for-next
Перенёс ещё 6 коммитов. Провёл рефакторинг кода.
Перенёс оставшиеся коммиты в smb2-for-next: всего 28 патчей сверх ветки for-next.
Начал работу над установкой SMB2 соединения. Добился отсылки SMB2_negotiate и получения ответа от сервера Samba-3.6.0pre1. Дальше нужно будет перерабатывать cifs_demultiplex_thread, чтобы он научился распознавать SMB2 пакеты. Ветка smb2-for-next-experimental: http://git.etersoft.ru/people/piastry/packages/?p=cifs-2.6.git;a=shortlog;h=refs/heads/smb2-for-next-experimental
Переработал cifs_demultiplex_tread: http://git.etersoft.ru/people/piastry/packages/?p=cifs-2.6.git;a=commitdiff;h=1cf02d769f54b81105fea4b32028507c55158508
После обсуждения со Стивом Френчем выяснилось, что ветка for-next была переработана и надо будет перекинуть патчи в неё (исправив конфликты) в порядке: сначала cifs патчи, потом smb2. Далее выянилось, что ветка сломана (не собирается) - отправил патч, исправляющий сборку.
Применил следующие патчи поверх текущей for-next ветки: CIFS: directio read/write cleanups CIFS: Simplify invalidate part (try #5) Отправил запрос на их слияние.
Патчи приняты в for-next.
Выяснилось, что патч cifs: keep BCC in little-endian format (try #2) содержит предупреждения по стилю - отправил разработчику письмо. После разрешения данной ситуации надо будет пробросить все патчи для cifs и на них уже положить патчи для smb2.
Обсудил со Стивом Френчем ситуацию по патчам: какие cifs патчи следует принять перед smb2 патчами.
Применил DFS патчи в ветку for-next: http://git.etersoft.ru/people/piastry/packages/?p=cifs-2.6.git;a=shortlog;h=refs/heads/for-next
Написал свои соображения по поводу организации очереди запросов при установленном сервером лимите: http://article.gmane.org/gmane.linux.kernel.cifs/3245
Обсудил со Стивом Френчем ситуацию по патчам.
Обновил и проверил собираемость текущих патчей для принятия на обновленной master ветке в апстрим.
Отправил патч для man страницы cifs - исправил ошибку в описании опций монтирования serverino и noserverino, замеченную тут: http://bugs.etersoft.ru/show_bug.cgi?id=7302#c2.
Разделил оставшиеся smb2 патчи на две части: влияющие на существующие cifs файлы и добавляющие или влияющие на новые smb2* файлы. Создал две ветки: 1) http://git.etersoft.ru/people/piastry/packages/?p=cifs-2.6.git;a=shortlog;h=refs/heads/cifs-patches 2) http://git.etersoft.ru/people/piastry/packages/?p=cifs-2.6.git;a=shortlog;h=refs/heads/smb2-patches
Получил письмо от разработчика апстрим, что патч simplify invalidate part принёс регрессию в connectathon basic test5. Разобрался с этой системой тестирования, выявил ошибку, исправил и отправил патч в рассылку.
Выявил проблему, найденную в комментарии http://bugs.etersoft.ru/show_bug.cgi?id=6633#c19 - вызывался два раза kfree на одном и том же указателе. Исправил проблему и отправил патч в апстрим.
Занимался багом из http://www.spinics.net/lists/linux-cifs/msg03946.html. Начал исследование кода VFS и NFS на предмет возможных путей решения проблемы.
(В ответ на comment #46) > Занимался багом из http://www.spinics.net/lists/linux-cifs/msg03946.html. Начал > исследование кода VFS и NFS на предмет возможных путей решения проблемы. Продолжил заниматься данным багом. Создал патч, которые использует следующее решение: корню суперблока (superblock root) и всем последующим выдаётся dentry без айнода (negative dentry). Как только мы достигаем точки корня файловой системы (mount root) мы запрашиваем информацию с сервера, создаём айнод и заполняем его. Таким обзразом, мы не запрашиваем информацию с сервера о нетребуемых компанентах пути, что исключает возможность падения с ошибкой "permission denied" при монтировании с //server/share/a/b в случаях, когда мы имеем права на b, но не имеем на a.
Занимался вышеописанной проблемой. Предложенное решение несколько выходит за рамки логики работы VFS. На основе идеи из рассылки предложил другой вариант решения: сохранять указатели на новую dentry по хэшу полного имени в вызовах cifs_get_root и cifs_lookup, и затем использовать их при запросе таких же имён.
Обнаружил ошибку в апстримной CIFS в ядре v3.0 (неправильная максимальная возможная длина пакета записи). Поправил, отправил патч в рассылку.
Занимался правкой патчей SMB2 для модуля CIFS в ядро 3.2. Столкнулся с проблемой неработоспособности кода, полученного путём rebase с патчами demultiplex thread и асинхронной записи. Далее буду более подробно разбираться с проблемой.
Разобрался с вышеописанной проблемой. Проблема заключалась, что под структуры сообщений выделялось не то количество памяти в следствии неправильно определённой структуры в kmem_cache_create. Провёл rebase со всеми патчами из текущей ветки cifs-2.6 и simplify demultiplex series.
Создал две общие ветку патчей для 3.2: 1) rebase на текущий master из cifs-2.6 http://git.etersoft.ru/people/piastry/packages?p=cifs-2.6.git;a=shortlog;h=refs/heads/cifs-3.2-current 2) rebase на demultiplex thrad patchset http://git.etersoft.ru/people/piastry/packages?p=cifs-2.6.git;a=shortlog;h=refs/heads/cifs-3.2
Провёл rebase веток (cifs-3.2* и smb2-dev* с обновлённым апстрим). Патч http://bugs.etersoft.ru/show_bug.cgi?id=6517#c50 и первые два патча из режима кеширования блокировок в апстрим. Вчера ещё обнаружил проблему несоответсвия прочитанного файла файлу на сервере при использовании режима асинхронной записи. Сегодня выяснил, что проблема присутствует и на апстримном cifs. Провёл анализ файлов: разница составляет 128 последовательных байт.
(В ответ на comment #54) ... > Вчера ещё обнаружил проблему несоответсвия прочитанного файла файлу на сервере > при использовании режима асинхронной записи. Сегодня выяснил, что проблема > присутствует и на апстримном cifs. Провёл анализ файлов: разница составляет 128 > последовательных байт. Занимался данной проблемой. Выяснил следующее: 1) Проблема всегда воспроизводится после загрузки системы с последующей загрузкой модуля CIFS, монтированием шары и чтением существующего файла. 2) Сетевой траффик, пойманный с помошью wireshark на сервере (Windows 7) и на клиенте разный - проверил и обнаружил то же различие в пакете ответа в той самой области, которая различна после чтения файла с файлом оригиналом (пакет ответа на сервере виден правильный, а на клиенте с ошибкой). 3) Область различия в файлах всегда около 128 байт, но проявляется в разных местах. 4) Проблема не зависит от возможно испорченного сетевого кабеля - использовал два разных с одинаковыми результатами. Таким образом, видимо, проблема не в CIFS модуле, а в драйвере сетевой карты или самом сетевом адапрете на моём ноутбуке. Отписал эти соображения в рассылку.
Выяснил, что при включении опции sign (подпись и проверка подписи пакетов) в dmesg появляется сообщение "Unexpected SMB signature", что позволяет отследить ошибку.
Попробовал сценарий возврата EAGAIN в случае неправильной сигнатуры и проблема исчезла (с опцией signed). Провёл rebase веток cifs-3.2, cifs-3.2-current, smb2-dev, smb2-dev-kconfig, smb2-dev-patched. Обнаружил ошибку в серии патчей асинхронного чтения, исправил и отправил патч. Создал новую ветку cifs-3.2, которая представляет собой rebase всех текущих патчей относительно серии патчей асинхронного чтения.
(В ответ на comment #57) > Создал новую ветку cifs-3.2, которая представляет собой rebase всех текущих имелось ввиду cifs-3.2-aread > патчей относительно серии патчей асинхронного чтения. Занимался веткой cifs-3.2-aread. Исправил ошибки работы асинхронного чтения для SMB2. Далее в процессе тестирования с помощью connectathon test suite исправил ошибки чтения директории, создания и удаления файлов. Далее продолжу работу над прохождением connectathon test suite.
Обнаружил ошибку в cifs_readv_complete, исправил и отправил в рассылку. Отложил тестирование с помощью Connectathon test suite и проводил стресс тестирование с помощью dbench с одним активным клиентом. Выявил отсутствие операции statfs для SMB2 и проблему обработки STATUS_PENDING сообщений от сервера. После исправлений dbench тест прошёл для одного клиента. Так же провёл rebase ветки cifs-3.2-aread и переименовал её в cifs-3.2.
Провёл тестирование ветки cifs-3.2, исправил некоторые ошибки и почистил код. На данный момент ветка проходит dbench тест с тремя клиентами.
Работал над задачей из http://bugs.etersoft.ru/show_bug.cgi?id=6517#c47. После исправления текущего патча обнаружил другие несовпадения с принятыми положениями VFS относительного того, что negative dentry не должна иметь потомков в дереве файловой системы.
Патчи из ветки cifs-3.2 приняты в апстрим (SMB2 и lock patchset). Оформил и отправил SMB2 патчи в рассылку, чтобы сделать данное событие общеизвестным.
Провёл чистку веток в репозитории cifs-2.6.
Данная бага себя исчерпала. Разбил её на две: http://bugs.etersoft.ru/show_bug.cgi?id=7814 - работа с репозиториями http://bugs.etersoft.ru/show_bug.cgi?id=7815 - собирательная по задачам заработки
