mhddfs — Монтирование нескольких разделов в одну директорию

    Хочу рассказать о том, как смонтироват в одну директорию два раздела.
    Честно говоря, никогда не задумывался о такой возможности, пока не попался клиент с подобным пожеланием. Поначалу мне показалось что это невозможно, но покопавшись в интернете нашел пару интересных статей. За основу в работе была взята статья с сайта 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. Если верить источнику, то монтировать в одну директорию можно более двух разделов и с разными файловыми системами. На практике я это не проверял, подтвердить не могу.
    Share post
    AdBlock has stolen the banner, but banners are not teeth — they will be back

    More
    Ads

    Comments 41

      0
      mdadm linear чем не угодил то?
        +1
        Во-первых одним из условий клиента было никаких RAID массивов… Как бы странно это не звучало. А во-вторых, на мой взгляд, этот вариант намного проще. Можно увеличивать объединённый раздел, добавляя третий, четвёртый и более диск не пересоздавая никаких массивов. Более того, добавлять разделы можно не пустыми, а уже с файлами. Может я не прав?
          +2
          Более того, добавлять разделы можно не пустыми, а уже с файлами.

          А как разрешаются конфликты? Если, к примеру, на нескольких разделах имеются файлы/директории с одинаковым именем, то что и как будет видно/доступно?
            0
            Судя по страничке автора ФС, конфликты разрешаются по принципу тапочек. Но это так, первое впечатление, я не вчитывался.
            +1
            Чувак, ты не прав как минимум дважды:

            1. Для этого есть LVM (отлично гуглится)
            2. Вот эта вот фиговина, она через fuse. То есть, про скорость надо забыть вообще, в принципе.
              +1
              2. Вот эта вот фиговина, она через fuse. То есть, про скорость надо забыть вообще, в принципе.
              Опять смешиваете понятия throughput и latency?
                –7
                Ваще без разницы чего мерить. Оно fuse.
                  0
                  FUSE практически никак не влияет на скорость линейной записи. Копирование тяжёлого файла пройдёт с одинаковой скоростью что через драйвер ext4, что через ntfs-3g. А вот latency, да, будет выше.
                    –6
                    Чувак, ты сильно неправ.
                      +3
                      Пруфы можно? А то я тоже использую FUSE, на больших файлах проблем не наблюдаю.
                      +7
                      ntfs-3g read\write чревато 100% CPU load
                  +3
                  LVM/Linear RAID пришлось бы накатывать сверху, с потерей данных дисков, да и делалось это, как я предполагаю, для другого.
                  Я использую aufs3, он ядерный и работает быстро. Объединяю 5 дисков своей файлопомойки, с балансировкой записи на тот диск, где места больше всего. У каждого диска одинаковая структура директорий, и преимущества такого подхода для файлопомойки очевидны:
                  • Потеря только части данных (фильмов, мультиков, музыки) при выходе одного диска из строя. Причем часто так случается, что директория исчезает не вся, а в ней пропадает только часть, например, часть эпизодов сериала. Так как это файлопомойка, перекачать сериал не составляет проблемы.
                  • Возможность работы только с частью подключенных дисков
                  • Возможность работы вообще без aufs и его настройки

                  А минус для меня всего один — не такая высокая скорость работы, как была бы в Raid 0.

                  cc: mikes
                    0
                    А если на такой комплект дисков пишется несколько файлов одновременно — суммарная скорость ведь получается выше?
                      0
                      Да. Если файлы пишутся параллельно, например, торрент-клиентом или двумя разными программами, то да, выше, а если вы просто копируете файлы, например, через cp, то он копирует линейно, и скорость равна скорости одного диска, на который происходит запись в данный момент.
                        0
                        Из моего опыта (советы ниже больше касаются mhddfs, но частично применимы к aufs/overlayfs) настоятельно советую писать файлы напрямую на диски, т.к. запись в объединенную папку может привести к вылету (для mhddfs).
                        Количество параллельных запросов на запись никак не ускорит работу (для mhddfs — aufs/overlayfs не тестировал так)! Запись идет последовательно до заполнения (с учетом mlimit для mhddfs) первого диска по списку, потом второго и т.д. до последнего. А еще это позволяет иметь несколько копий одного и того же файла (виден будет первый, но если его удалить, то второй, если и его удалить (что интересно, удалять можно прямо с объединенной папки, каждая итерация будет удалять вышестоящий файл!), то третий и так до последнего диска в списке).

                        Для поклонников RAID: ничто не мешает объединять уже защищенные массивы, получив, например, аналог RAID1+0, только предсказуемый и более отказоустойчивый (и, разумеется, менее быстрый если не думать головой, а вот если ее приложить, то скорость будет такая же или чуть выше).

                        Т.е. опять же, планирование и еще раз планирование! И тогда результат будет очень и очень хорошим.
                          0
                          aufs все же работает не так, и у меня никогда не было проблем с записью в объединенную папку.
                            0
                            Не так. И это заметно в нюансах.
                            Насчет записи я подчеркнул что не тестировал aufs на параллельной записи, да и просто на запись не использую по одной очень важной причине — aufs требует полноценного перемонтирования при отмонтировании диска из перечня, а вот mhddfs это спокойно делает. Чтобы было понятно — когда список дисков это пустые директории /d1, /d2, /d3, то смонтировав их в /d123 и затем примонтировав настоящие диски в /d1, /d2, /d3 мы сразу же получим объединенное содержимое для mhddfs, но не для aufs/overlayfs, которые покажут пустоту, как и до монтирования настоящих дисков.

                            Вместе с тем, aufs/overlayfs заметно быстрее работает, более стабилен и меньше грузит процессор. Поэтому для файлового хранилища я делаю виртуальные объединенные read-only папки на overlayfs. И перемонтирую их когда меняются входящие в состав диски.
                              0
                              Думаю, это решается дерганием mount -o remount на смонтированный aufs. Ни разу не пробовал, если честно.
                                0
                                Это помогает только со сбросом кеша (например когда файлы менялись на вложенных дисках напрямую), но при монтировании есть привязка к физической файловой системе и если поверх смонтировано что-то еще, то aufs его не учитывает (а еще, не позволяет отмонтировать — хаки через удаление/изменение дисков, входящих в объединение, показали что не стоит оно того, проще все перемонтировать — будет гарантированный результат).

                                Я сейчас сделал простой тест (overlayfs):
                                1) смонтировал поверх /d1 папку со своим содержимым через bind
                                2) проверил — в /d123 содержимого нет ни сразу, ни после сброса кеша, ни после remount
                                Т.е. overlayfs продолжает «видеть» файловую ниже, а не ту, что смонтировали поверх (касается и нормальных non-bind mount).
                  0
                  А что это, если не raid? Пусть не аппаратный, и пусть не через md, но суть-то от этого не меняется — получается JBOD. Возможно заказчик «особенный».
                    0
                    Ну увеличите Вы раздел. А писаться-то куда должны файлы? Создали директорию — где она создастся? На первом разделе, к примеру. Если в неё писать — где будут данные? Опять на первом разделе. И в чём состоит увеличение объединённого раздела? (а если будут файлы писаться на все разделы по очереди по мере заполнения — то это вообще мрак). Конечно, для каких-то применений это полезно, но оень для редких. Символьные ссылки проще.
                      0
                      Да, mhddfs решает проблему и балансировки записи в том числе. Символьными ссылками вы такого не сделаете. Смотрите мой ответ чуть выше, зачем конкретно мне это нужно.
                      0
                      lvm?
                    +2
                    Моя статья на эту тему, конечно, была давно, но актуальности не потеряла:

                    habrahabr.ru/post/98742
                      0
                      Согласен с выводами. Когда выбирал Union FS для домашнего сервачка, именно aufs оказалась как самым надежным, так и самым производительным решением.
                      И тем более жаль, что Дзюндзиро совсем недавно приоставновил ее разработку…
                        0
                        Я тоже пострадал немного когда перешел на linux-4 ядро откуда выкинули aufs (Debian), но в настоящий момент OverlayFS выглядит ничем не хуже (для моих сценариев).
                          +1
                          Так же использую aufs на домашнем сервере: по расписанию либо по тригеру в папку Video (Plex+plexconnect+appletv) монтируется папки с только детским контентом либо с взрослым (не adult only, а обычные фильмы и сериалы, которые детям смотреть не нужно). В качестве тригера используется наличие в домашней wi-fi сети телефона мамы или папы. нужно еще telegram прикрутить.
                          Ядро давно не обновлял именно из-за aufs, спасибо за OverlayFS, пойду читать.
                      0
                      Примерно того же можно достичь простыми символьными ссылками для всех файлов/директорий второй ФС. Может быть, это и хотел клиент?
                        0
                        Думаю, что клиент хотел разумного объяснения почему лучше не монтировать 2 раздела в одну директорию.
                        0
                        А как же unionfs?
                          0
                          UnionFS, aufs, OverlayFS
                            0
                            Последний в ядре, кстати.
                              0
                              Использую его с 4-го ядра (когда AuFS выкинули и заменили на OverlayFS) для объединения 50+ точек монтирования. Работает неплохо, скорость выше чем через mhddfs (хотя его я тоже по-своему люблю — главное что он очень простой, однако плохо подходит для записи).
                                0
                                А вот разъясните мне про OverlayFS. Если я правильно понял ман, то запись в смонтированную директорию всегда идет только на одну и ту же систему, и ничего близко похожего на политики выбора fs для записи (типа сreate=pmfs в aufs) я там не нашел.
                            +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
                              +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.
                                0
                                Да, mergefs значительно лучше.
                                Но данное решение только для dev-серверов, никак не может быть продакшен решением.
                                Есть еще UnionFs, aufs, overlayfs
                                0
                                Эта штука весьма глючная. И очень, очень медленная… — В своё время игрался. — Выплюнул. :(
                                  0
                                  Не ясно как решаются конфликты:
                                  1) Создание(удаление, изменение) файла(папки) — на каком разделе будет создан(удален, изменен) файл(папка)?
                                  2) как будет вести себя система, когда есть на разных разделах два разных файла, но с одинаковыми именами?
                                    +1
                                    Там довольно простой алгоритм, какой путь идёт раньше (позже? проверю и напишу апдейт), тот и будет мастером, дубликат не виден.
                                      +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

                                    Only users with full accounts can post comments. Log in, please.