Про суть и текущее состояние технологий UNIONFS (апрель 2007)

После обследования положения вещей в области UNIONFS, накроопал заметку в форуме openvz http://forum.openvz.org/index.php?t=tree&goto=12011&#msg_12011

А тут я повторяю ее содержимое... Интересно, кто что думает по этому поводу...
Проработка состояния UNIONFS выявила следующее...

Существуют unionfs 1.x, unionfs 2.x и aufs. unionfs 1.x -- по утверждениям авторов KMOPPIX и SLAX страдают нестабильностью и создают слишком много и необоснованно whiteouts (такие спецфайлы-маски для индикации удаленных файлов) unionfs 2.x -- это обрезанный до минимума 1.x (и измененной местами семантикой) с целью вклбчения в ядро 2.6.20-2.6.21. Утверждается, что тестировался и отлажен значительно лучше 1.x aufs -- это ветка 1.x, которую начал дорабатывать японец, делал это долго и упорно, учитывая просьбы разработчиков LiveCD. Поэтому новый SLAX (6.0) планирует использовать aufs, а KNOPPIX 5.1.0+ -- уже использует aufs. Фича, которой похоже нет в unionfs -- возможность объединения до 32000 каталогов (правда за счет падения производительности файловых операций)

В общем наверно правильнее начать с unionfs 2.x (прилепить ее к openvz-el) и уж по результатам судить о дальнейших путях.

Сама идея unionfs сулит много, RedHat выдвинул концепцию StateLess workstation (или что-то вроде этого). На SourceForge существуеи MapFS проект от прооизводителя сетевых дисков Levanta (NAS/SAN), который напоминает unionfs (только там надо специально описывать, что видит клиент). Ибо такой способ позволяет эфективно разделять сетевые ресурсы между рабочими станциями.

PS: Если MapFS работает нормально, то может составить альтернативу для unionfs при работе openvz-окружений. MapFS -- это "mount -o bind" из многих каталогов (а не из одного) в один, причем оригинальные каталоги не меняются. Технология не использует white-out-файлы (меняется описание экспорта и rw-часть). RW-часть только одна. Имеет fsck-программу.

Лично мне MapFS по духу ближе и понятнее UNIONS. Если кто помнит ARVID (бэкап-система на домашнем видике), то там использовалась концепция именно MapFS: имеем на диске метаданные (имена файлов и каталогов, их атрибуты), а сами данные -- на видике и не всегда доступны. Но можно осуществлять поиск файлов, выполнять реорганизацию структуры каталогов (перемешать, переименовывать) не трогая мафон. А для UNIONFS, чтоб изменить структуру результирующего объединения, надо менять или сами составляющие (ветви), или в rw-каталлоге сочинять кучу white-out. Однако для UNIONFS похоже невозможно реорганизовать структуру без копирования в rw-каталог

PPS: различие в технологиях UnionFS и MapFS мне видится как различие между скоростью/размером при компиляции программ. UnionFS очень быстро подключает в объединение каталоги без необходимости какой-либо предварительной подготовки. MapFS при подключении каталога должна просканировать его и внести описание всей его структуры в view (файл метаданных). Или это должно быть проделано заранее. Зато при работе UnionFS имеет кучу проблем (те самые whiteout-файлы, которые плодятся быстрей кроликов) и попытки соптимизировать задачу перемещения файлов по каталогу без создания его копии в rw-части.

MapFS "медленно запрягает, зато быстрей едет"...

MapFS можно рассматривать как каталог с симлинками на различные read-only файлы и механизм copy-out в rw-часть при изменении файла с автоматической корректировкой сим-линка. Если учитывать, что symlink успешно используются в таких дистрах как GOBO-linux (для имитирования стандартной структуры каталогов в то время как каждый пакет на самом деле хранится в своем подкаталоге), то MapFS -- хороший кандидат на РЕАЛЬНО работающую реализацию unionfs (главное простую в реализации)

Но пока непонятно, зачем нужна copy-out часть, когда можно просто на автомате заменить symlink на сам файл? Оптимизация для размера copy-out? Тогда нужно хранить и bit-карту