| openvz-el5 и unionfs [message #11931] |
Thu, 12 April 2007 07:28  |
|
|
А как обстоит дело с unionfs для openvz-el5? Без patch-ей от RedHat (в openvz-028test015 например) проблема вроде была только с количеством аргументов в вызове permission-функции (точно не помню). А в openvz-el5 проблема уже в отсутствующих членах структур.
Похоже, что в openvz-el5 все хорошо, но мне туда не надо. Ибо вряд ли RedHat будет заморачиваться с доработкой unionfs для Enterprise
[Updated on: Thu, 12 April 2007 07:29] Report message to a moderator |
|
|
|
| Re: openvz-el5 и unionfs [message #12002 is a reply to message #11931] |
Fri, 13 April 2007 18:05  |
|
|
|
Посмотрел внутрь 018to027.patch (сделал по запросу из GIT-репозитария). То есть patch для преобразования версии 028test018 в 028stab027. Процесс стабилизации, как выяснилось, состоял в откате модификации для функции permissions. То есть в стабильной опять нормальное количество аргументов и unionfs уже патчить не надо (для варианта 028stab027+). Как обстоит дело с unionfs в openvz-el5 -- этот вопрос еще не изучен.
|
|
|
|
| Re: openvz-el5 и unionfs [message #12011 is a reply to message #11931] |
Sat, 14 April 2007 04:11 |
|
|
Проработка состояния 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-карту
[Updated on: Sat, 14 April 2007 06:09] Report message to a moderator |
|
|
|
| Re: openvz-el5 и unionfs [message #12012 is a reply to message #11931] |
Sat, 14 April 2007 09:16 |
|
|
Сделал diff между RHEL5 kernel 2.6.18-8.el5 и openvz 028stab027.1 (вроде одной версии должны быть). Наблюдаю массивный откат в RHEL версии всяких переименований, которые в openvz в наличии. Например в openvz нет inode.i_private (он переименован в inode.u.generic_ip).
А я то удивляюсь: почему MapFS не хочет для openvz компилится...
Вывод: 028stab для реальной жизни не пригоден. Возможна куча проблем с драйверами-модулями (так что все -- на openvz в варианте rhel5)
PS: хотя в gentoo-sources-2.6.28-r7 inode.i_private тоже отсуствует
[Updated on: Sat, 14 April 2007 14:46] Report message to a moderator |
|
|
|
|
|
|
|
| Re: openvz-el5 и unionfs [message #12138 is a reply to message #12030] |
Wed, 18 April 2007 07:56 |
|
|
Про aufs и unionfs...
В unionfs как-то неправильно организовали разработку. Для 2.6.18 бери версию 1.4, для 2.6.16 бери версию... CVS репозитарий только для unionfs я не нашел (он вроде как есть, но сильно засекречен). Все исправления ошибок идут в новую версию, старые версии не правятся. Портировать unionfs 2.0 в 2.6.18 -- проблемная задача (мне не удалось)
aufs имеет cvs хранилище, версия подходит под все ядра, есть инструкция для включения aufs в состав Linux-исходников...
Вывод: для версий ядра меньше 2.6.21 (туда предположительно войдет unionfs 2.0) unionfs -- странный кандидат.
PS: попробовал MapFS. Если исключить трудности загрузки модуля (использует не экспортируемые фунции ядра, адреса которых надо найти в System.map и подать модулю в качестве аргументов), то все работает. Однако для использования в качестве замены unionfs надо написать:
1) скрипт для загрузки ядерного модуля mapfs (который сам ищет нужные адреса функций)
2) скрипт для добавления/удаления каталога в/из MapFS. При добавлении каталога нужно его просканировать и добавить описание его структуры в MapFS, а при удалении каталога -- сканировать MapFS и удалять все файлы, которые находятся в удаляемом каталоге.
В общем -- это для второй попытки. Для начала хочется иметь более стандартный вариант. А далее -- по обстоятельствам. Основная проблема, которой страдал unionfs 1.x -- трудности реорганизовать структуру каталогов (перемещение каталога). Этим страдал и CVS (если читать коменты в spec-файле от RHEL5). Возможно, в aufs проблема решена (hard-линки между ветвями)
|
|
|
|
OpenVZ Forum
Members
Search
Help
Register
Login
Home
, поэтому патч был откатан назад.
