система FreeBSD 6.1
Имеется файловый архив, размещенный на нескольких hdd. Каждый раздел смонтирован (в rw режиме) в "/data/hdd<номер>". Требуется сделать в "/filearchive" read-only представление данного архива со "слитыми" файловыми системами, т.е. например при наличии "/data/hdd1/Muzik/Soft Machine/1971 - Virtually" и "/data/hdd2/Muzik/Soft Machine/1969 - Volume Two"
ls "/filearchive/Muzik/Soft Machine" должа показать
1969 - Volume Two
1971 - VirtuallyКонтент достаточно статичен (музыка и фильмы на домашней файлопомойке), доступ в "слитом" виде нужен исключительно read-only, все манипуляции (удаление, добавление) с контентом производятся через /data/hdd<номер> и относительно редки. По идее содержимое дисков не перекрывается, в случае же [нештатного] наличия на разных дисках файла с одним и тем же путем совершенно безразлично как сия ситуация будет обработана.
известные мне (и не устраивающие меня) решения
1) RAID. Категорически не устраивает. Даже если забить на экономическую неоправданость в рамках данной задачи raid01/raid10/raid5 и гимор с восстановлением raid0/jbod (в случае падения одного винта бэкап разворачивать на все), то остается главный минус - невозможность легко наращивать по необходимости дисковую емкость добавлением новых винтов.
2) В силу относительной статичности содержимого - запускающийся [руками] после каждого изменения контента скрипт, создающий в /filearchive структуру директорий из /data/hdd<номер> и хардлинки на соотв. файлы. Вариант прямолинейный, надежный и не очень-то неудобный, но мое чувство прекрасного он нарушает :)
3) unionfs. Почти то что надо, однако во-первых настораживает секция BUGS из мана, во-вторых unionfs предназначен в первую очередь для обеспечения rw-доступа с помощью copy-on-write, что порождает разные заморочки типа [совершенно нежелательной в данном случае] дубликации на каждом слое структуры каталогов всех нижележащих слоев. Да и из пушки по воробьям это получается.
4) Попрактиковаться в kernel programming и руководствуясь nullfs/unionfs как экзамплом сваять то, что нужно. Но не займусь ли я изобретением велосипеда ?
Собственно вопросы:
1) существует ли более заточеный под описаную задачу аналог unionfs ?
2) насколько unionfs надежен (при условии read-only доступа к "разделу") ?
3) как в unionfs можно отключить автоматическое дублирование директорий нижних уровней на верхних ?
4) Какие еще варианты решения вы можете предложить ?спасибо.
Говорят что на FreeBSD аналог LVM - Vinum. Сам не пробовал. Но LVM использовал - удобно...
>Говорят что на FreeBSD аналог LVM - Vinum. Сам не пробовал. Но
>LVM использовал - удобно...не поможет, ибо человек непонятного хочет и как сие объяснить - тоже непонятно, с одной
стороны вроде бы понимает о том что пишет, с другой стороны вроде нет, в смысле хочет
какой-то интеллектуевый fs-layer...
>с другой стороны вроде нет, в смысле хочет какой-то интеллектуевый fs-layer...
хотение интеллектуального fs-layer'а == непониманию того чего хочу ? в принципе unionfs и есть интеллектуальный fs-layer, только черезчур интеллектуальный для данной задачи.
спасибо, посмотрю.
>1) RAID. Категорически не устраивает. Даже если забить на экономическую неоправданость в
>рамках данной задачи raid01/raid10/raid5 и гимор с восстановлением raid0/jbod (в случае
>падения одного винта бэкап разворачивать на все), то остается главный минус
>- невозможность легко наращивать по необходимости дисковую емкость добавлением новых винтов.Есть еще gconcat, поможет с добавлением новых дисков.
>2) В силу относительной статичности содержимого - запускающийся [руками] после каждого изменения контента скрипт, создающий в /filearchive структуру директорий из /data/hdd<номер> и хардлинки на соотв. файлы. Вариант прямолинейный, надежный и не очень-то неудобный, но мое чувство прекрасного он нарушает :)
Только не хард, а софт-линки.
>3) unionfs. Почти то что надо, однако во-первых настораживает секция BUGS из
>мана, во-вторых unionfs предназначен в первую очередь для обеспечения rw-доступа с
>помощью copy-on-write, что порождает разные заморочки типа [совершенно нежелательной в данном
>случае] дубликации на каждом слое структуры каталогов всех нижележащих слоев. Да
>и из пушки по воробьям это получается.Наиболее прямой вариант, но работает только в CURRENT. Если у машинки основное предназначение - хранение этих самых файлов, то можно и поставить.
>4) Попрактиковаться в kernel programming и руководствуясь nullfs/unionfs как экзамплом сваять то,
>что нужно. Но не займусь ли я изобретением велосипеда ?Легче уж спортировать unionfs из CURRENT в 6.1 :)
>Есть еще gconcat, поможет с добавлением новых дисков.
вариант конечно, но все равно не то немного - хотелось бы, чтобы на каждом диске была своя собственная независимая fs.>Только не хард, а софт-линки.
да, блин, то, что хардлинки на фс на другом девайсе показывать не будут я как-то упустил из виду. софты не подходят по другим соображениям, такчто вариант отпадает.>>3) unionfs.
>Наиболее прямой вариант, но работает только в CURRENT.
на 6.1 release - вполне работает, правда мне не нравится как.
>>Есть еще gconcat, поможет с добавлением новых дисков.
>вариант конечно, но все равно не то немного - хотелось бы, чтобы
>на каждом диске была своя собственная независимая fs.в таком случае не морочьте людям голову, кроме loopback-fs вам ничего не поможет,
так что либо nullfs, либо unionfs, за стабильность при их большом количестве и
интенсивном дисковом I/O вряд ли кто поручится. Хоть и вылизывают...
>так что либо nullfs
nullfs ? а с ним как можно нужного результата достигнуть ?
>>так что либо nullfs
>nullfs ? а с ним как можно нужного результата достигнуть ?# man mount_nullfs
про стабильность читать списки рассылки freebsd или поиск по ним
>>>так что либо nullfs
>>nullfs ? а с ним как можно нужного результата достигнуть ?
>
># man mount_nullfs
Вдумчиво перечитал еще раз. Как с помощью nullfs слить содержимое нескольких директорий в одну так и не понял.
>>>3) unionfs.
>>Наиболее прямой вариант, но работает только в CURRENT.
>на 6.1 release - вполне работает, правда мне не нравится как.В CURRENT код unionfs переписан с нуля.
попутно возник вопрос - что произойдет с виртуальним диском vinum / gconcat при смерти одного из сцепленных накопителей ?
помоему вам надо приложить руки на уровне выше, в приложении через которое производится доступ к содержимому дисков... в нем весь файловый архив будет виден едино, а в конфигураторе будет видно диски по отдельности, ну и при заливке система будет в полуавтомате забивать свободное место...собери рейд, 5 винтов по 250 - почти 1 Тб получится...
>попутно возник вопрос - что произойдет с виртуальним диском vinum / gconcat
>при смерти одного из сцепленных накопителей ?при gconcat - задница произойдет (а что произойдет в случае умирания ОДНОГО из дисков
без gconcat?)в vinum - если подразумевается raid-0 тоже будет задница и что?