Pull to refresh

Comments 42

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

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

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

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

cc: mikes
А если на такой комплект дисков пишется несколько файлов одновременно — суммарная скорость ведь получается выше?
Да. Если файлы пишутся параллельно, например, торрент-клиентом или двумя разными программами, то да, выше, а если вы просто копируете файлы, например, через cp, то он копирует линейно, и скорость равна скорости одного диска, на который происходит запись в данный момент.
Из моего опыта (советы ниже больше касаются mhddfs, но частично применимы к aufs/overlayfs) настоятельно советую писать файлы напрямую на диски, т.к. запись в объединенную папку может привести к вылету (для mhddfs).
Количество параллельных запросов на запись никак не ускорит работу (для 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. И перемонтирую их когда меняются входящие в состав диски.
Думаю, это решается дерганием mount -o remount на смонтированный aufs. Ни разу не пробовал, если честно.
Это помогает только со сбросом кеша (например когда файлы менялись на вложенных дисках напрямую), но при монтировании есть привязка к физической файловой системе и если поверх смонтировано что-то еще, то aufs его не учитывает (а еще, не позволяет отмонтировать — хаки через удаление/изменение дисков, входящих в объединение, показали что не стоит оно того, проще все перемонтировать — будет гарантированный результат).

Я сейчас сделал простой тест (overlayfs):
1) смонтировал поверх /d1 папку со своим содержимым через bind
2) проверил — в /d123 содержимого нет ни сразу, ни после сброса кеша, ни после remount
Т.е. overlayfs продолжает «видеть» файловую ниже, а не ту, что смонтировали поверх (касается и нормальных non-bind mount).
А что это, если не raid? Пусть не аппаратный, и пусть не через md, но суть-то от этого не меняется — получается JBOD. Возможно заказчик «особенный».
Ну увеличите Вы раздел. А писаться-то куда должны файлы? Создали директорию — где она создастся? На первом разделе, к примеру. Если в неё писать — где будут данные? Опять на первом разделе. И в чём состоит увеличение объединённого раздела? (а если будут файлы писаться на все разделы по очереди по мере заполнения — то это вообще мрак). Конечно, для каких-то применений это полезно, но оень для редких. Символьные ссылки проще.
Да, mhddfs решает проблему и балансировки записи в том числе. Символьными ссылками вы такого не сделаете. Смотрите мой ответ чуть выше, зачем конкретно мне это нужно.
Согласен с выводами. Когда выбирал Union FS для домашнего сервачка, именно aufs оказалась как самым надежным, так и самым производительным решением.
И тем более жаль, что Дзюндзиро совсем недавно приоставновил ее разработку…
Я тоже пострадал немного когда перешел на linux-4 ядро откуда выкинули aufs (Debian), но в настоящий момент OverlayFS выглядит ничем не хуже (для моих сценариев).
Так же использую aufs на домашнем сервере: по расписанию либо по тригеру в папку Video (Plex+plexconnect+appletv) монтируется папки с только детским контентом либо с взрослым (не adult only, а обычные фильмы и сериалы, которые детям смотреть не нужно). В качестве тригера используется наличие в домашней wi-fi сети телефона мамы или папы. нужно еще telegram прикрутить.
Ядро давно не обновлял именно из-за aufs, спасибо за OverlayFS, пойду читать.
Примерно того же можно достичь простыми символьными ссылками для всех файлов/директорий второй ФС. Может быть, это и хотел клиент?
Думаю, что клиент хотел разумного объяснения почему лучше не монтировать 2 раздела в одну директорию.
Использую его с 4-го ядра (когда AuFS выкинули и заменили на OverlayFS) для объединения 50+ точек монтирования. Работает неплохо, скорость выше чем через mhddfs (хотя его я тоже по-своему люблю — главное что он очень простой, однако плохо подходит для записи).
А вот разъясните мне про OverlayFS. Если я правильно понял ман, то запись в смонтированную директорию всегда идет только на одну и ту же систему, и ничего близко похожего на политики выбора fs для записи (типа сreate=pmfs в aufs) я там не нашел.
Вставлю свои 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
Отлично! Берем статью двухлетней давности, тупо копипастим, отдаем в продакшен, и даже не удосуживаемся заглянуть на страничку разработчика. Еще и хабраюзерам советуем.
А между тем, там написано:

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.
Да, mergefs значительно лучше.
Но данное решение только для dev-серверов, никак не может быть продакшен решением.
Есть еще UnionFs, aufs, overlayfs
Эта штука весьма глючная. И очень, очень медленная… — В своё время игрался. — Выплюнул. :(
UFO just landed and posted this here
Там довольно простой алгоритм, какой путь идёт раньше (позже? проверю и напишу апдейт), тот и будет мастером, дубликат не виден.
Там довольно простой алгоритм, какой путь идёт раньше, тот и будет мастером, дубликат не виден:
> /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 году ?

Sign up to leave a comment.

Articles