Честно говоря, никогда не задумывался о такой возможности, пока не попался клиент с подобным пожеланием. Поначалу мне показалось что это невозможно, но покопавшись в интернете нашел пару интересных статей. За основу в работе была взята статья с сайта hotbits.ru. Но в статье монтировали разделы одного и того же диска, мне же предстояло смонтировать разделы с разных дисков. Как оказалось, нет никакой разницы.
В качестве операционной системы использовалась Ubuntu 14.04.
Первое что необходимо сделать, это создать сами разделы.
В моём случае это был раздел /dev/sda3 находящийся на системном диске и раздел /dev/sdb1, который занимал весь второй диск.
Монтируем оба раздела. Для этого в /mnt создадим точки монтирования.
~# mkdir /mnt/sda3
~# mkdir /mnt/sdb1
~# mount /dev/sda3 /mnt/sda3
~# mount /dev/sdb1 /mnt/sdb1
Смотрим что получилось
~# df -h
Filesystem Size Used Avail Use% Mounted on
/dev/sda1 85G 1.1G 79G 2% /
none 4.0K 0 4.0K 0% /sys/fs/cgroup
udev 3.9G 4.0K 3.9G 1% /dev
tmpfs 796M 412K 796M 1% /run
none 5.0M 0 5.0M 0% /run/lock
none 3.9G 0 3.9G 0% /run/shm
none 100M 0 100M 0% /run/user
/dev/sda3 826G 73M 784G 1% /mnt/sda3
/dev/sdb1 917G 72M 871G 1% /mnt/sdb1
Далее устанавливаем специальную утилиту mhddfs, которая и позволит нам объеденить оба эти раздела в один.
~# apt-get install mhddfs
Монтировать оба раздела будем в директорию в /home.
Для этого выполним:
~# mhddfs /mnt/sda3,/mnt/sdb1 /home
mhddfs: directory '/mnt/sda3' added to list
mhddfs: directory '/mnt/sdb1' added to list
mhddfs: mount to: /home
mhddfs: move size limit 4294967296 bytes
Проверим
~# df -h
Filesystem Size Used Avail Use% Mounted on
/dev/sda1 85G 1.2G 79G 2% /
none 4.0K 0 4.0K 0% /sys/fs/cgroup
udev 3.9G 4.0K 3.9G 1% /dev
tmpfs 796M 412K 796M 1% /run
none 5.0M 0 5.0M 0% /run/lock
none 3.9G 0 3.9G 0% /run/shm
none 100M 0 100M 0% /run/user
/dev/sda3 826G 73M 784G 1% /mnt/sda3
/dev/sdb1 917G 72M 871G 1% /mnt/sdb1
/mnt/sda3;/mnt/sdb1 1.8T 144M 1.7T 1% /home
Всё смонтировалось и в итоге мы имеем вместо двух раздельных точек монтирования размером 826Гб и 917Гб, одну объёмом 1.8Tб.
В оригинальной статье использовалась опция монтирования -o allow_other, которая позволяет иметь доступ к разделу другим пользователям, но мне она не нужна, потому что пользователь в системе один.
А теперь отмонтируем (или размонтируем) /home и сделаем так, чтобы разделы монтировались при загрузке системы. Это естественно, никто не будет каждый раз монтировать разделы вручную, но для монтирования во время загрузки нужно добавить модуль fuse.
~# echo "fuse" >> /etc/modules
И теперь подправим /etc/fstab добавив в него следующие строки:
/dev/sda3 /mnt/sda3 ext4 defaults 0 2
/dev/sdb1 /mnt/sdb1 ext4 defaults 0 2
mhddfs#/mnt/sda3,/mnt/sdb1 /home fuse defaults,mlimit=10G 0 0
mlimit=10G показывает, что на любом из разделов должно оставаться не менее 10 гигабайт свободного места. Это значит, что если свободного места останется 10 гигабайт, то на этот раздел больше не будет производиться запись.
И теперь осталось проверить всё ли мы правильно прописали в fstab. Делаем:
~# mount -a
mhddfs: directory '/mnt/sda3' added to list
mhddfs: directory '/mnt/sdb1' added to list
mhddfs: mount to: /home
mhddfs: move size limit 10737418240 bytes
Ошибок нет, следовательно всё в порядке. Проверяем:
~# df -h
Filesystem Size Used Avail Use% Mounted on
/dev/sda1 85G 1.2G 79G 2% /
none 4.0K 0 4.0K 0% /sys/fs/cgroup
udev 3.9G 4.0K 3.9G 1% /dev
tmpfs 796M 412K 796M 1% /run
none 5.0M 0 5.0M 0% /run/lock
none 3.9G 0 3.9G 0% /run/shm
none 100M 0 100M 0% /run/user
/dev/sda3 826G 73M 784G 1% /mnt/sda3
/dev/sdb1 917G 72M 871G 1% /mnt/sdb1
/mnt/sda3;/mnt/sdb1 1.8T 144M 1.7T 1% /home
Всё на месте, задача выполнена. Для уверенности можете перезагрузить систему.
И кстати, копировать файлы можно как в объединённую директорию /home, так и в директории /mnt/sda3 или /mnt/sdb1. Файлы всё равно появляются в /home как будто они лежат на одном разделе. Причём подмечено, что если копировать в /home, то файлы копируются на раздел, который находится первым в порядке монтирования, то есть на sda3. Предполагаю, что это будет происходить до тех пор, пока не будет достигнут лимит в 10 Гб, и только затем файлы начнут копироваться на sdb1.
На этом всё.
P.S. Если верить источнику, то монтировать в одну директорию можно более двух разделов и с разными файловыми системами. На практике я это не проверял, подтвердить не могу.
Комментарии (41)
pfactum
16.08.2015 21:22+2Моя статья на эту тему, конечно, была давно, но актуальности не потеряла:
habrahabr.ru/post/98742
dmitryredkin
16.08.2015 22:05Согласен с выводами. Когда выбирал Union FS для домашнего сервачка, именно aufs оказалась как самым надежным, так и самым производительным решением.
И тем более жаль, что Дзюндзиро совсем недавно приоставновил ее разработку…
alexkuzko
17.08.2015 22:39Я тоже пострадал немного когда перешел на linux-4 ядро откуда выкинули aufs (Debian), но в настоящий момент OverlayFS выглядит ничем не хуже (для моих сценариев).
tea
18.08.2015 12:31+1Так же использую aufs на домашнем сервере: по расписанию либо по тригеру в папку Video (Plex+plexconnect+appletv) монтируется папки с только детским контентом либо с взрослым (не adult only, а обычные фильмы и сериалы, которые детям смотреть не нужно). В качестве тригера используется наличие в домашней wi-fi сети телефона мамы или папы. нужно еще telegram прикрутить.
Ядро давно не обновлял именно из-за aufs, спасибо за OverlayFS, пойду читать.
Mirraz
16.08.2015 23:54UnionFS, aufs, OverlayFS
ValdikSS
17.08.2015 00:33Последний в ядре, кстати.
alexkuzko
17.08.2015 22:25Использую его с 4-го ядра (когда AuFS выкинули и заменили на OverlayFS) для объединения 50+ точек монтирования. Работает неплохо, скорость выше чем через mhddfs (хотя его я тоже по-своему люблю — главное что он очень простой, однако плохо подходит для записи).
dmitryredkin
20.08.2015 13:33А вот разъясните мне про OverlayFS. Если я правильно понял ман, то запись в смонтированную директорию всегда идет только на одну и ту же систему, и ничего близко похожего на политики выбора fs для записи (типа сreate=pmfs в aufs) я там не нашел.
alexyr
17.08.2015 07:49+3Вставлю свои 5 копеек — btrfs. Если нужен не рейд, а просто общая ёмкость:
# Use full capacity of multiple drives with different sizes (metadata mirrored, data not mirrored and not striped)
mkfs.btrfs -d single /dev/sdb /dev/sdc
ComodoHacker
17.08.2015 10:11+14Отлично! Берем статью двухлетней давности, тупо копипастим, отдаем в продакшен, и даже не удосуживаемся заглянуть на страничку разработчика. Еще и хабраюзерам советуем.
А между тем, там написано:
PLEASE DON'T USE THIS
mhddfs is buggy, unsupported, and has some major security issues.
mergerfs provides more functionality in general and is actively maintained.
agent_0007
17.08.2015 13:30Да, mergefs значительно лучше.
Но данное решение только для dev-серверов, никак не может быть продакшен решением.
Есть еще UnionFs, aufs, overlayfs
VGusev2007
17.08.2015 12:03Эта штука весьма глючная. И очень, очень медленная… — В своё время игрался. — Выплюнул. :(
k1b0rg
17.08.2015 12:18Не ясно как решаются конфликты:
1) Создание(удаление, изменение) файла(папки) — на каком разделе будет создан(удален, изменен) файл(папка)?
2) как будет вести себя система, когда есть на разных разделах два разных файла, но с одинаковыми именами?alexkuzko
17.08.2015 14:56+1Там довольно простой алгоритм, какой путь идёт раньше (позже? проверю и напишу апдейт), тот и будет мастером, дубликат не виден.
alexkuzko
17.08.2015 15:02+1Там довольно простой алгоритм, какой путь идёт раньше, тот и будет мастером, дубликат не виден:
> /srv/storage-storage;/srv/system-storage -> /srv/storage
echo 1 > /srv/storage-storage/test
echo 2 > /srv/system-storage/test
# cat /srv/storage/test
1
# rm /srv/storage-storage/test
# cat /srv/storage/test
2
mikes
mdadm linear чем не угодил то?
draven072
Во-первых одним из условий клиента было никаких RAID массивов… Как бы странно это не звучало. А во-вторых, на мой взгляд, этот вариант намного проще. Можно увеличивать объединённый раздел, добавляя третий, четвёртый и более диск не пересоздавая никаких массивов. Более того, добавлять разделы можно не пустыми, а уже с файлами. Может я не прав?
murminathor
А как разрешаются конфликты? Если, к примеру, на нескольких разделах имеются файлы/директории с одинаковым именем, то что и как будет видно/доступно?
dmiceman
Судя по страничке автора ФС, конфликты разрешаются по принципу тапочек. Но это так, первое впечатление, я не вчитывался.
dmiceman
Чувак, ты не прав как минимум дважды:
1. Для этого есть LVM (отлично гуглится)
2. Вот эта вот фиговина, она через fuse. То есть, про скорость надо забыть вообще, в принципе.
kekekeks
dmiceman
Ваще без разницы чего мерить. Оно fuse.
kekekeks
FUSE практически никак не влияет на скорость линейной записи. Копирование тяжёлого файла пройдёт с одинаковой скоростью что через драйвер ext4, что через ntfs-3g. А вот latency, да, будет выше.
dmiceman
Чувак, ты сильно неправ.
ComodoHacker
Пруфы можно? А то я тоже использую FUSE, на больших файлах проблем не наблюдаю.
wrewolf
ntfs-3g read\write чревато 100% CPU load
ValdikSS
LVM/Linear RAID пришлось бы накатывать сверху, с потерей данных дисков, да и делалось это, как я предполагаю, для другого.
Я использую aufs3, он ядерный и работает быстро. Объединяю 5 дисков своей файлопомойки, с балансировкой записи на тот диск, где места больше всего. У каждого диска одинаковая структура директорий, и преимущества такого подхода для файлопомойки очевидны:
А минус для меня всего один — не такая высокая скорость работы, как была бы в Raid 0.
cc: mikes
k0ldbl00d
А если на такой комплект дисков пишется несколько файлов одновременно — суммарная скорость ведь получается выше?
ValdikSS
Да. Если файлы пишутся параллельно, например, торрент-клиентом или двумя разными программами, то да, выше, а если вы просто копируете файлы, например, через cp, то он копирует линейно, и скорость равна скорости одного диска, на который происходит запись в данный момент.
alexkuzko
Из моего опыта (советы ниже больше касаются mhddfs, но частично применимы к aufs/overlayfs) настоятельно советую писать файлы напрямую на диски, т.к. запись в объединенную папку может привести к вылету (для mhddfs).
Количество параллельных запросов на запись никак не ускорит работу (для mhddfs — aufs/overlayfs не тестировал так)! Запись идет последовательно до заполнения (с учетом mlimit для mhddfs) первого диска по списку, потом второго и т.д. до последнего. А еще это позволяет иметь несколько копий одного и того же файла (виден будет первый, но если его удалить, то второй, если и его удалить (что интересно, удалять можно прямо с объединенной папки, каждая итерация будет удалять вышестоящий файл!), то третий и так до последнего диска в списке).
Для поклонников RAID: ничто не мешает объединять уже защищенные массивы, получив, например, аналог RAID1+0, только предсказуемый и более отказоустойчивый (и, разумеется, менее быстрый если не думать головой, а вот если ее приложить, то скорость будет такая же или чуть выше).
Т.е. опять же, планирование и еще раз планирование! И тогда результат будет очень и очень хорошим.
ValdikSS
aufs все же работает не так, и у меня никогда не было проблем с записью в объединенную папку.
alexkuzko
Не так. И это заметно в нюансах.
Насчет записи я подчеркнул что не тестировал aufs на параллельной записи, да и просто на запись не использую по одной очень важной причине — aufs требует полноценного перемонтирования при отмонтировании диска из перечня, а вот mhddfs это спокойно делает. Чтобы было понятно — когда список дисков это пустые директории /d1, /d2, /d3, то смонтировав их в /d123 и затем примонтировав настоящие диски в /d1, /d2, /d3 мы сразу же получим объединенное содержимое для mhddfs, но не для aufs/overlayfs, которые покажут пустоту, как и до монтирования настоящих дисков.
Вместе с тем, aufs/overlayfs заметно быстрее работает, более стабилен и меньше грузит процессор. Поэтому для файлового хранилища я делаю виртуальные объединенные read-only папки на overlayfs. И перемонтирую их когда меняются входящие в состав диски.
ValdikSS
Думаю, это решается дерганием mount -o remount на смонтированный aufs. Ни разу не пробовал, если честно.
alexkuzko
Это помогает только со сбросом кеша (например когда файлы менялись на вложенных дисках напрямую), но при монтировании есть привязка к физической файловой системе и если поверх смонтировано что-то еще, то aufs его не учитывает (а еще, не позволяет отмонтировать — хаки через удаление/изменение дисков, входящих в объединение, показали что не стоит оно того, проще все перемонтировать — будет гарантированный результат).
Я сейчас сделал простой тест (overlayfs):
1) смонтировал поверх /d1 папку со своим содержимым через bind
2) проверил — в /d123 содержимого нет ни сразу, ни после сброса кеша, ни после remount
Т.е. overlayfs продолжает «видеть» файловую ниже, а не ту, что смонтировали поверх (касается и нормальных non-bind mount).
k0ldbl00d
А что это, если не raid? Пусть не аппаратный, и пусть не через md, но суть-то от этого не меняется — получается JBOD. Возможно заказчик «особенный».
Pilat
Ну увеличите Вы раздел. А писаться-то куда должны файлы? Создали директорию — где она создастся? На первом разделе, к примеру. Если в неё писать — где будут данные? Опять на первом разделе. И в чём состоит увеличение объединённого раздела? (а если будут файлы писаться на все разделы по очереди по мере заполнения — то это вообще мрак). Конечно, для каких-то применений это полезно, но оень для редких. Символьные ссылки проще.
ValdikSS
Да, mhddfs решает проблему и балансировки записи в том числе. Символьными ссылками вы такого не сделаете. Смотрите мой ответ чуть выше, зачем конкретно мне это нужно.
amarao
lvm?