>что-то я отстал от жизни - подобных открытых ФС уже вроде есть
>несколько штук, или нет? Вообще-то ни одной. GPFS наиболее близка к задуманному функционалу, но она закрыта. Все известные находятся полностью в userspace, поэтому не предоставляют POSIX API. Из того, что есть, ни одна система не предоставляет достаточной избыточности данных и метаданных, в некоторых есть начальная репликация метаданных, например в Lustre master-slave метадата сервер, но одного сервера недостаточно. В ceph есть распараллеливание метадата нагрузки между несколькими серверами, но ни один из них не дублируется, так что при его падении невозможно получить данные, опять же все в userspace, так что нет POSIX API, какую-нибудь базу данных не запустить. Хотя Ceph работает над этим и есть клиент, который будет привязан только к btrfs. В PVFS2 та же проблема - нет избыточности сервера метаданных. В glusterfs вообще до последнего времени не было избыточности даже данных, сейчас это работает очень нестабильно. В ядре есть несколько распределенных файловых систем (ocfs и gfs с номерами в конце), но они завязаны на userspace сервер блокировок, который ну очень кривой. RH сейчас переводит свой cluster suite с gfs на новую технологию из-за кривости дизайна GFS: блокировки на уровне блоков диска очень плохо масштабируются. OCFS2 вообще 32-битная система. Точнее она 64-битная, но использует ядерный JBD, который 32-битный. JBD2 должен быть 64-битным, но пока это только разработка для ext4.
Примерный план разработки таков:
В основном работа была над ядерной клиентской частью, userspace сервер
достаточно простой, но дальше основаная процесс будет над ним. В ближайших планах по клиентской части поддержка транзакций и блокировок. Так же инвалидация кеша данных клиентов при параллельной записи.
Из-за отсутствия транзакций некоторые операции с метаданными (как например распаковка большого архива) требуют синхронной записи (т.е. запись не может стартовать, пока не создан объект), что снижает производительность (иногда до уровня NFS).
В пользовательском сервере будет добавлена возможность отвечать на lookup и readdir запросы не данными об объекте (информация, которую предоставляет системный вызов stat(2)), а адресом другого сервера, где этот объект находится, т.о. можно будет параллельно считывать данные с нескольких серверов. Пока планируется хранить целиком объекты на отдельных серверах (т.е. весь файл будет на одном сервере, пока без возможности хранить часть на одном, а часть на другом сервере, но это только пока).
Насчет асинхронного режима, imho, это наиболее интересная часть: клиент может сделать очень много запросов на чтение данных (или директории), а ответы могут приходить (вообще говоря с разных серверов, но это только в планах) в любое время и в любом порядке. Т.о. можно например "подсовывать" информацию о том, что новые объекты были добавлены в директорию (другим клиентом). Это уже реализовано, но код закоментирован в сервере, т.к. не очень понятно, нужно ли это. Таким же асинхронным способом будут приходить сообщения об инвалидации кеша.
Насчет зеркалирования: имеется ввиду возможность хранить один и тот же объект на разных корневых директориях, т.е. клиент видит только один объект, а на самом деле он был скопирован сервером например на разные машины/в разные корневые директории, чтобы не было проблем с чтением содержимого (т.е. клиент создал файл /mnt/test/1, значит он не должен видеть, что на самом деле он живет еще и в /mnt/backup/1 или /mnt/.test/1). Также в обязательном порядке будет зеркалирование с учетом имен, т.е. например '*.jpg' положить в /root1 и /root2, '*.conf' только в '/var/etc' и т.п. правила (пока в виде простейшего регулярного выражения).
Автор подробнее описал это в блоге.
