Евгений Поляков объявил о выходе релиза POHMELFS, высокопроизводительной сетевой файловой системы с поддержкой кэширования данных и мета-данных на стороне клиента. Основная цель проекта - разработка средства для распределённой параллельной обработки данных.

POHMELFS находится на начальной стадии развития, многие задуманные возможности еще не реализованы. Релиз включает в себя концептуальный код сервера, работающего как пользовательское приложение, и клиента, реализованного на уровне ядра.

Основные возможности:

• Поддержание локального кэша для данных и мета-данных, согласованного для всех узлов использующих ФС;
• Обработка данных и событий в асинхронном режиме, за исключением операций с жёсткими и символическими ссылками;
• Гибкая архитектура, оптимизированная для обмена данных по сети, включая возможность объединения нескольких операций в одну управляющую команду передаваемую по сети;
• Одна из первичных целей проекта - высокая производительность;
• Быстрый многопоточный сервер, работающий на пользовательском уровне, по производительности заметно опережающий асинхронный режим NFS сервера, работающего на уровне ядра.

Планы на будущее:

• Расширение сервера в направлении возможности хранения данных на нескольких устройствах (что-то похожее на зеркалирование), сперва сохраняя данные в разные локальные директории, а затем реализовав возможность зеркалирования на внешние NFS или POHMELFS разделы;
• Дополнение клиента и сервера средствами параллельного чтения/записи данных с соседних узлов;
• Реализация средств аутентификации и шифрования передаваемых по сети данных;
• Возможность автоматического переключения на запасной сервер в случае сбоя текущего;
• Увеличение производительности передачи данных из асинхронных ядерных потоков в userspace память, через использование функции copy_to_user().

Дополнение: Евгений Поляков, рассказал про некоторые особенности и поделился планами:

"В основном работа была над ядерной клиентской частью, userspace сервер достаточно простой, но дальше основной процесс будет над ним. В ближайших планах по клиентской части поддержка транзакций и блокировок. Так же инвалидация кеша данных клиентов при параллельной записи.

Из-за отсутствия транзакций некоторые операции с метаданными (как например распаковка большого архива) требуют синхронной записи (т.е. запись не может стартовать, пока не создан объект), что снижает производительность (иногда до уровня NFS).

В пользовательском сервере будет добавлена возможность отвечать на lookup и readdir запросы не данными об объекте (информация, которую предоставляет системный вызов stat(2)), а адресом другого сервера, где этот объект находится, т.о. можно будет параллельно считывать данные с нескольких серверов. Пока планируется хранить целиком объекты на отдельных серверах (т.е. весь файл будет на одном сервере, пока без возможности хранить часть на одном, а часть на другом сервере, но это только пока).

Насчёт асинхронного режима, по моему мнению, это наиболее интересная (так и хочется сказать революционная :) часть: клиент может сделать очень много запросов на чтение данных (или директории), а ответы могут приходить (вообще говоря с разных серверов, но это только в планах) в любое время и в любом порядке. Т.о. можно например "подсовывать" информацию о том, что новые объекты были добавлены в директорию (другим клиентом). Это уже реализовано, но код закомментирован в сервере, т.к. не очень понятно, нужно ли это. Таким же асинхронным способом будут приходить сообщения об инвалидации кеша (наверное это будет готово завтра или, если привезут велосипед, то на следующей неделе :).

Насчёт зеркалирования: имеется ввиду возможность хранить один и тот же объект на разных корневых директориях, т.е. клиент видит только один объект, а на самом деле он был скопирован сервером например на разные машины/в разные корневые директории, чтобы не было проблем с чтением содержимого (т.е. клиент создал файл /mnt/test/1, значит он не должен видеть, что на самом деле он живет еще и в /mnt/backup/1 или /mnt/.test/1). Также в обязательном порядке будет зеркалирование с учетом имен, т.е. например '*.jpg' положить в /root1 и /root2, '*.conf' только в '/var/etc' и т.п. правила (пока в виде простейшего регулярного выражения).

По сути работы осталось не очень много (главное это представление о том, что же вообще хочется от системы, и как оно должно быть реализовано), так что такой "дизайн" уже готов. Хотя назвать это полноценным дизайном трудно, скорее эволюционное развитие (где-то я это уже слышал про развитие ядра, сам же и критиковал :)."