Комментарии 42
mdadm linear чем не угодил то?
Во-первых одним из условий клиента было никаких RAID массивов… Как бы странно это не звучало. А во-вторых, на мой взгляд, этот вариант намного проще. Можно увеличивать объединённый раздел, добавляя третий, четвёртый и более диск не пересоздавая никаких массивов. Более того, добавлять разделы можно не пустыми, а уже с файлами. Может я не прав?
Более того, добавлять разделы можно не пустыми, а уже с файлами.
А как разрешаются конфликты? Если, к примеру, на нескольких разделах имеются файлы/директории с одинаковым именем, то что и как будет видно/доступно?
Чувак, ты не прав как минимум дважды:
1. Для этого есть LVM (отлично гуглится)
2. Вот эта вот фиговина, она через fuse. То есть, про скорость надо забыть вообще, в принципе.
1. Для этого есть LVM (отлично гуглится)
2. Вот эта вот фиговина, она через fuse. То есть, про скорость надо забыть вообще, в принципе.
2. Вот эта вот фиговина, она через fuse. То есть, про скорость надо забыть вообще, в принципе.Опять смешиваете понятия throughput и latency?
LVM/Linear RAID пришлось бы накатывать сверху, с потерей данных дисков, да и делалось это, как я предполагаю, для другого.
Я использую aufs3, он ядерный и работает быстро. Объединяю 5 дисков своей файлопомойки, с балансировкой записи на тот диск, где места больше всего. У каждого диска одинаковая структура директорий, и преимущества такого подхода для файлопомойки очевидны:
А минус для меня всего один — не такая высокая скорость работы, как была бы в Raid 0.
cc: mikes
Я использую aufs3, он ядерный и работает быстро. Объединяю 5 дисков своей файлопомойки, с балансировкой записи на тот диск, где места больше всего. У каждого диска одинаковая структура директорий, и преимущества такого подхода для файлопомойки очевидны:
- Потеря только части данных (фильмов, мультиков, музыки) при выходе одного диска из строя. Причем часто так случается, что директория исчезает не вся, а в ней пропадает только часть, например, часть эпизодов сериала. Так как это файлопомойка, перекачать сериал не составляет проблемы.
- Возможность работы только с частью подключенных дисков
- Возможность работы вообще без aufs и его настройки
А минус для меня всего один — не такая высокая скорость работы, как была бы в Raid 0.
cc: mikes
А если на такой комплект дисков пишется несколько файлов одновременно — суммарная скорость ведь получается выше?
Да. Если файлы пишутся параллельно, например, торрент-клиентом или двумя разными программами, то да, выше, а если вы просто копируете файлы, например, через cp, то он копирует линейно, и скорость равна скорости одного диска, на который происходит запись в данный момент.
Из моего опыта (советы ниже больше касаются mhddfs, но частично применимы к aufs/overlayfs) настоятельно советую писать файлы напрямую на диски, т.к. запись в объединенную папку может привести к вылету (для mhddfs).
Количество параллельных запросов на запись никак не ускорит работу (для mhddfs — aufs/overlayfs не тестировал так)! Запись идет последовательно до заполнения (с учетом mlimit для mhddfs) первого диска по списку, потом второго и т.д. до последнего. А еще это позволяет иметь несколько копий одного и того же файла (виден будет первый, но если его удалить, то второй, если и его удалить (что интересно, удалять можно прямо с объединенной папки, каждая итерация будет удалять вышестоящий файл!), то третий и так до последнего диска в списке).
Для поклонников RAID: ничто не мешает объединять уже защищенные массивы, получив, например, аналог RAID1+0, только предсказуемый и более отказоустойчивый (и, разумеется, менее быстрый если не думать головой, а вот если ее приложить, то скорость будет такая же или чуть выше).
Т.е. опять же, планирование и еще раз планирование! И тогда результат будет очень и очень хорошим.
Количество параллельных запросов на запись никак не ускорит работу (для mhddfs — aufs/overlayfs не тестировал так)! Запись идет последовательно до заполнения (с учетом mlimit для mhddfs) первого диска по списку, потом второго и т.д. до последнего. А еще это позволяет иметь несколько копий одного и того же файла (виден будет первый, но если его удалить, то второй, если и его удалить (что интересно, удалять можно прямо с объединенной папки, каждая итерация будет удалять вышестоящий файл!), то третий и так до последнего диска в списке).
Для поклонников RAID: ничто не мешает объединять уже защищенные массивы, получив, например, аналог RAID1+0, только предсказуемый и более отказоустойчивый (и, разумеется, менее быстрый если не думать головой, а вот если ее приложить, то скорость будет такая же или чуть выше).
Т.е. опять же, планирование и еще раз планирование! И тогда результат будет очень и очень хорошим.
aufs все же работает не так, и у меня никогда не было проблем с записью в объединенную папку.
Не так. И это заметно в нюансах.
Насчет записи я подчеркнул что не тестировал aufs на параллельной записи, да и просто на запись не использую по одной очень важной причине — aufs требует полноценного перемонтирования при отмонтировании диска из перечня, а вот mhddfs это спокойно делает. Чтобы было понятно — когда список дисков это пустые директории /d1, /d2, /d3, то смонтировав их в /d123 и затем примонтировав настоящие диски в /d1, /d2, /d3 мы сразу же получим объединенное содержимое для mhddfs, но не для aufs/overlayfs, которые покажут пустоту, как и до монтирования настоящих дисков.
Вместе с тем, aufs/overlayfs заметно быстрее работает, более стабилен и меньше грузит процессор. Поэтому для файлового хранилища я делаю виртуальные объединенные read-only папки на overlayfs. И перемонтирую их когда меняются входящие в состав диски.
Насчет записи я подчеркнул что не тестировал aufs на параллельной записи, да и просто на запись не использую по одной очень важной причине — aufs требует полноценного перемонтирования при отмонтировании диска из перечня, а вот mhddfs это спокойно делает. Чтобы было понятно — когда список дисков это пустые директории /d1, /d2, /d3, то смонтировав их в /d123 и затем примонтировав настоящие диски в /d1, /d2, /d3 мы сразу же получим объединенное содержимое для mhddfs, но не для aufs/overlayfs, которые покажут пустоту, как и до монтирования настоящих дисков.
Вместе с тем, aufs/overlayfs заметно быстрее работает, более стабилен и меньше грузит процессор. Поэтому для файлового хранилища я делаю виртуальные объединенные read-only папки на overlayfs. И перемонтирую их когда меняются входящие в состав диски.
Думаю, это решается дерганием mount -o remount на смонтированный aufs. Ни разу не пробовал, если честно.
Это помогает только со сбросом кеша (например когда файлы менялись на вложенных дисках напрямую), но при монтировании есть привязка к физической файловой системе и если поверх смонтировано что-то еще, то aufs его не учитывает (а еще, не позволяет отмонтировать — хаки через удаление/изменение дисков, входящих в объединение, показали что не стоит оно того, проще все перемонтировать — будет гарантированный результат).
Я сейчас сделал простой тест (overlayfs):
1) смонтировал поверх /d1 папку со своим содержимым через bind
2) проверил — в /d123 содержимого нет ни сразу, ни после сброса кеша, ни после remount
Т.е. overlayfs продолжает «видеть» файловую ниже, а не ту, что смонтировали поверх (касается и нормальных non-bind mount).
Я сейчас сделал простой тест (overlayfs):
1) смонтировал поверх /d1 папку со своим содержимым через bind
2) проверил — в /d123 содержимого нет ни сразу, ни после сброса кеша, ни после remount
Т.е. overlayfs продолжает «видеть» файловую ниже, а не ту, что смонтировали поверх (касается и нормальных non-bind mount).
А что это, если не raid? Пусть не аппаратный, и пусть не через md, но суть-то от этого не меняется — получается JBOD. Возможно заказчик «особенный».
Ну увеличите Вы раздел. А писаться-то куда должны файлы? Создали директорию — где она создастся? На первом разделе, к примеру. Если в неё писать — где будут данные? Опять на первом разделе. И в чём состоит увеличение объединённого раздела? (а если будут файлы писаться на все разделы по очереди по мере заполнения — то это вообще мрак). Конечно, для каких-то применений это полезно, но оень для редких. Символьные ссылки проще.
lvm?
Согласен с выводами. Когда выбирал Union FS для домашнего сервачка, именно aufs оказалась как самым надежным, так и самым производительным решением.
И тем более жаль, что Дзюндзиро совсем недавно приоставновил ее разработку…
И тем более жаль, что Дзюндзиро совсем недавно приоставновил ее разработку…
Я тоже пострадал немного когда перешел на linux-4 ядро откуда выкинули aufs (Debian), но в настоящий момент OverlayFS выглядит ничем не хуже (для моих сценариев).
Так же использую aufs на домашнем сервере: по расписанию либо по тригеру в папку Video (Plex+plexconnect+appletv) монтируется папки с только детским контентом либо с взрослым (не adult only, а обычные фильмы и сериалы, которые детям смотреть не нужно). В качестве тригера используется наличие в домашней wi-fi сети телефона мамы или папы. нужно еще telegram прикрутить.
Ядро давно не обновлял именно из-за aufs, спасибо за OverlayFS, пойду читать.
Ядро давно не обновлял именно из-за aufs, спасибо за OverlayFS, пойду читать.
Примерно того же можно достичь простыми символьными ссылками для всех файлов/директорий второй ФС. Может быть, это и хотел клиент?
А как же unionfs?
UnionFS, aufs, OverlayFS
Вставлю свои 5 копеек — btrfs. Если нужен не рейд, а просто общая ёмкость:
# Use full capacity of multiple drives with different sizes (metadata mirrored, data not mirrored and not striped)
# 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
Отлично! Берем статью двухлетней давности, тупо копипастим, отдаем в продакшен, и даже не удосуживаемся заглянуть на страничку разработчика. Еще и хабраюзерам советуем.
А между тем, там написано:
А между тем, там написано:
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.
Эта штука весьма глючная. И очень, очень медленная… — В своё время игрался. — Выплюнул. :(
НЛО прилетело и опубликовало эту надпись здесь
Там довольно простой алгоритм, какой путь идёт раньше (позже? проверю и напишу апдейт), тот и будет мастером, дубликат не виден.
Там довольно простой алгоритм, какой путь идёт раньше, тот и будет мастером, дубликат не виден:
> /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
> /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
Статья написана много лет назад, но все же спрошу -
Скажите пожалуйста - что актуально для ubuntu 20 в 2022 году ?
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
mhddfs — Монтирование нескольких разделов в одну директорию