Объединение нескольких разделов в один без потери информации

    Задача


    Необходимо объединить несколько существующих разделов в один без потери информации. Такое может случиться, если заранее не был задействован LVM, а необходимо расширить пространство, например, для торрентов.

    Решения


    Решений существует как минимум два.

    aufs2


    aufs2 — файловая система, реализующая каскадно-объединённое монтирование для файловых систем Linux. Помимо унаследованного от UnionFS функционала здесь реализованы RW-ветки и балансировка записи, что идеально подходит для решения поставленной задачи.

    Следует заметить, что aufs2 не включена в mainline-ядро. Но она есть:
    • в Debian Lenny (в Testing и Sid уже, к сожалению, нет);
    • в Ubuntu (так как LiveCD Ubuntu построен с применением этой ФС);
    • в Zen-kernel и Liquorix.

    Также можно самостоятельно пропатчить и собрать ядро, используя standalone-версию aufs2. Для дебиановцев рекомендую, если нет желания возиться с компиляцией ядра, воспользоваться готовыми пакетами Liquorix, подключив репозиторий так, как указано на странице проекта.

    Если с ядром разобрались, то необходимо позаботиться о userspace-утилитах. В Debian'е есть готовые пакеты (несмотря на отсутствие поддержки со стороны ядра), поэтому их можно поставить одной командой:

    sudo aptitude install aufs-tools

    Если готовых пакетов в дистрибутиве нет, их можно взять с официального сайта aufs.

    Теперь к делу. Допустим, есть два смонтированных раздела:
    • старый с кучей торрентов: /media/torrents;
    • и новый на только-что купленном винчестере: /media/new_storage.

    Для того, чтобы эти два раздела были видимы как один, необходимо выполнить следующую команду:

    sudo mount -t aufs none /media/storage -o br:/media/torrents=rw:/media/new_storage=rw,create=mfs,sum

    Здесь:
    • br: ветка1=rw: ветка2=rw:… — список т. н. веток, т. е. смонтированных разделов, которые будут объединены в один;
    • create=mfs — главный параметр, указывающий на то, что для записи будет выбираться та ветка, которая имеет больше свободного места. Без указания этого параметра «слойка» из разделов не будет работать так, как задумано;
    • sum — указывает, что в утилитах типа df или pydf будет выводиться суммарный размер разделов и свободного места на них для объединённого раздела.

    В /etc/fstab такая запись должна иметь вид:

    none /media/storage aufs br:/media/torrents=rw:/media/new_storage=rw,create=mfs,sum 0 0

    mhddfs


    В отличие от aufs, mhddfs — ФС пространства пользователя, работающая через fuse. В Debian'е есть готовый пакет, который устанавливается командой:

    sudo aptitude install mhddfs

    Монтирование производится командой:

    sudo mhddfs /media/torrents,/media/new_storage /media/storage -o default_permissions,allow_other

    В /etc/fstab соответствующая запись имеет вид:

    mhddfs#/media/torrents,/media/new_storage /media/storage fuse default_permissions,allow_other 0 0

    Стоит заметить, что ни aufs2, ни mhddfs не позволяют одному файлу находится частично на одном, частично — на другом разделе. Также отмечу, что после размонтирования слойки ко всем файлам будет доступ через исходные точки монтирования. Часть файлов окажется на одном разделе, часть — на другом.

    Выводы



    Если необходимо быстрое и простое решение, то большинству пользователей будет достаточно mhddfs. Но стоит помнить, что aufs2 работает на уровне ядра, поэтому производительность в этом случае выше. К тому же, mhddfs в значительно большей степени нагружает процессор, а скорость записи/считывания несколько ниже, чем в aufs2.

    Спасибо за внимание. Комментарии, замечания и пожелания приветствуются.
    Share post

    Similar posts

    AdBlock has stolen the banner, but banners are not teeth — they will be back

    More
    Ads

    Comments 30

      +2
      Насколько я слышал последнее обсуждение этих систем, все они рано или поздно показывали дырявость абстракции в самый неудачный момент. Подробностей, к сожалению, не помню.
        0
        Мне кажется для торентопомойки это абсолютно не критично.
          0
          Ну а мне всё же кажется, что лучше пересилить себя и сделать чистенький LVM)) А ещё лучше — RAID через mdadm, тогда даже избыточность для сохранности данных легко вставить. Всё же приведённые решения — откровенные костыли, и не важно, для чего они используются ;)
            0
            У LVM есть минусы: при отвале одного из дисков сносит всю файловую систему целиком, что может быть болезненным даже при не очень критичных данных. Одно дело восстанавливать информацию с одного погибшего диска и другое — с четырёх. У RAID тоже есть минусы: во-первых, он создаёт иллюзию надёжности и про резервное копирование в итоге часто забывают (к тому же тратится место), во-вторых, его не очень удобно расширять. Я, например, не знаю, как перенести массив с дисков по 1,5 ТБ на 2 ТБ, заменяя диски по очереди, а не сразу.
              –2
              У LVM да, есть минусы. А RAID не создаёт иллюзию, он действительно надежен. Чем вам например 10 RAID не угодил, или скажем RAID6. Программный RAID — это просто простой способ делать ваши бекапы. Ну а расширение… Да, нужны диски одинакового объёма или же сразу полная замена массива. Не считаю это минусом, поскольку реально это не вредит ничему.
                +2
                RAID любого уровня может спасти только от одной угрозы — физического выхода из строя носителя из строя. А с информацией, между тем, может случиться много чего занятного: выход из строя файловой системы, ошибка ПО или пользователя, приводящая к повреждению данных, диверсия, наконец. Причём в сумме это может оказаться гораздо более вероятным, чем подыхание диска. Таким образом фраза «программный RAID — это просто простой способ делать ваши бекапы» ­— не более чем миф. Если у меня будет два жёстких диска и нужно будет сделать из них максимально надёжную систему, я не стану делать из них RAID1, а поставлю один диск и буду время от времени подключать второй, чтобы скинуть на него бэкапы. А до рейда дело дойдёт, когда 1) появится больше носителей и 2) потребуется кроме надёжности обеспечить ещё и высокую доступность.
                  –4
                  Я не страдаю паранойей, поэтому считаю что правильно организованное хранилище на рейдах не требует в основном бекапа))) Если у вас конечно не информация, представляющая гостайну. ФС восстанавливается на раз при любых ошибках (кроме откровенных диверсий, ага), привет ext3/4, ошибка ПО, приводящая к rm -rf / — это круто, но пренебрежительно маловероятно, а потерять пару текущих файлов из-за ошибки ПО, с ним работающего — это не страшно и от этого бекапы не спасут. РЕально конечно надо делать бекапы важных данных, а рейд скорее использовать для отказоустойчивости системы, но фанатизм в бекапах при использовании рейда проявлять явно не стоит. То есть если рассматривать организацию отказоустойчивого хранилища, то я бы начал ровно наоборот: сначала рейд, а потом если получится отдельное место для бекапа. Плюс можно поверх рейда прикрутить LVM с ротирующимися снапшотами дня на три назад раз в 24 часа снимающимися, это чтобы защититься от случайного удаления файла пользователем вместо инкрементальных бекапов. Хотя это уменьшит скорость записи сильно, но обычно для сетевых хранилищ некритично.
                    +3
                    > Я не страдаю паранойей, поэтому считаю что правильно организованное
                    > хранилище на рейдах не требует в основном бекапа

                    Зеркальный рэйд спасает от гибели диска, но не спасает от случайного или намеренного удаления кем-то важных данных, ведь это удаление сразу будет отзеркалено на другие диски. Именно для этого и нужен регулярный бэкап.
                      –1
                      Это правда, я для этого использую LVM со снапшотами на трое суток назад))) Просто началось всё с иллюзии надёжности RAID. Он не создаёт иллюзию, он действительно надёжен, особенно в рамках приведённой задачи. Если вам нужны бекапы в целях защиты от шаловливых ручек — то тут уже ничего не попишешь. Часто на это забивают, зачастую кстати обоснованно. Зачем например бекап серверов без пользовательских данных — непонятно. А вот рейд на них может спасти от более реальных опасностей, как то выход диска из строя например.
                      0
                      > Я не страдаю паранойей
                      А стоило бы.
                      > ФС восстанавливается на раз при любых ошибках
                      Сама ФС, скорее всего, восстановится (хотя сталкивался и с убитой напрочь ext3), только базе, которая в этот момент меняла структуру таблиц, от этого лучше не станет, если не включать журналирование данных.
                      > ошибка ПО, приводящая к rm -rf / — это круто, но пренебрежительно маловероятно
                        0
                        Чёрт, рано отправилось.
                        > ошибка ПО, приводящая к rm -rf / — это круто, но пренебрежительно маловероятно
                        Ни разу не сталкивались с DELETE FROM xxx без WHERE, случайно попавшим в продакшн, поскольку программер забыл проверить дописываемую фичу? Или с утечкой пароля, из-за которой кто-то нехороший поправил ненравящиеся ему данные? Поздравляю.
                        > но фанатизм в бекапах при использовании рейда проявлять явно не стоит
                        А нафига нужны два экземпляра неправильных данных?
                        > Плюс можно поверх рейда прикрутить LVM с ротирующимися снапшотами дня на три назад
                        Вот это уже ближе к истине.
                        > Зачем например бекап серверов без пользовательских данных — непонятно.
                        А зачем нужны сервера без пользовательских данных?
                        0
                        Я тоже не страдал, теперь я в категории людей кто «уже делает бэкапы», после того как контроллер перестал видеть оба винта в массиве. К счастью все решилось, но несколько неприятных часов я пережил. :-D
            +2
            Кажется, вы забыли тег закрыть)
              0
              Если вы про h3, то спасибо, поправил.
            • UFO just landed and posted this here
                +1
                Узнать можно, хоть и не напрямую. Исходные точки монтирования вполне доступны для чтения и записи.
                +1
                Для справки: в Gentoo тоже есть sys-fs/aufs2 :)
                  +1
                  sys-fs/mhddfs тоже.
                  +1
                  По поводу Дебиана: aufs-tools есть и в тестинге и в анстейбле. Модуль ядра также есть в 2.6.32-5, которая в тестинге по умолчанию. А вот в 2.6.34 из экспериментальной ветки уже нет.
                  По задаче: ещё есть btrfs, которая позволяет подключить второй том к уже существующей ФС и даже распределить данные из первого поровну по обоим. Правда, он ещё сыроват и порою падает с кернель упсами.
                    0
                    как они работают с нфс? я давненько пробовал mhddfs экспортить но работало оно с ошибками, т.е. файлы прерывались в рандомные моменты. mhddfs в свою очередь еще и делает неплохую нагрузку на систему.
                      0
                      mhddfs не удалось завести с nfs. aufs лично я в такой связке не пробовал.
                        +1
                        Подтверждаю, mhddfs не работает с nfs. Пришлось прописать в установленной самбе
                    • UFO just landed and posted this here
                        0
                        в Ubuntu (так как LiveCD Ubuntu построен с применением этой ФС);

                        В каком месте она там? Вроде бы squashfs всегда использовался.
                          +1
                          Сначала монтируется RO squashfs, а поверх неё —RW aufs.
                          0
                          На самом деле очень большая проблема получить хранилище устойчивое к вылету одного диска с возможностью простой замены/добавления дисков. Самый простой вариант как мне кажется — это отказаться от RAID в пользу объединения через LVM и rsync критичных данных на отдельный хдд.
                            0
                            Я примерно к такому же схеме пришёл. Но некритичные данные терять тоже не очень хотелось бы.
                              0
                              Или разбивать диски на меньшие разделы, ставить их в RAID а потом на него еще LVM. Я сам этого не делаю, так как не нужно, но встречал много руководств, когда учился админинстрировать mdadm.
                              –1
                              что только не придумают, вместо того чтобы пользоваться одним целым разделом на весь диск.
                                –1
                                Стоит вспомнить, что ZFS лишена описанных в статье сложностей в работе по-умолчанию.

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