Выполнить предложенное можно, но эффект будет другим — в точке монтирования будет доступно последнее из смонтированных устройств.

Точнее они будут намонтированы поверх друг друга, то есть доступно будет последнее смонтированное устройство, при отмонтировании его будет доступно предпоследнее и так далее до первого смонтированного устройства.

Да, последующие перекрывают предыдущие. Отмонтирование последнего делает видимым предыдущий в «бутерброде».

Попробуй mhddfs

На серверах не только RAID и LVM бывает. Иногда и такие штуки, как HDFS встречаются. Но это довольно специфичные области серверов.

А вообще я обычно просто диск /media/data деалаю. Можешь это посмотреть. Я уже мусолил тему.

Кстати намного меньше команд надо выполнить в mhddfs. Спасибо!

UPD: погуглил про RAID и LVM

Вот тебе ещё слова:

• mdadm
• zfs
• btrfs

К словам btrfs и особенно zfs относись осторожно, ценные данные на них клади не ранее чем через год удачной и безошибочной эксплуатации.
(года четыре назад у меня на zfs zraid6 пропадали файлы субтитров и прочая мелочь к которой небыло долгое время обращений на чтение)

Ну а btrfs просто молодая и неопробованная в эксплуатации фс, хотя на одном диске без райда она работает отлично.

Если выберешь btrfs кастани меня, я тебе расскажу коекакие хитрости.

доступно будет последнее смонтированное устройство

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

Если выберешь btrfs кастани меня, я тебе расскажу коекакие хитрости.

Все хотят видеть. Хитрости в студию ;) Заранее спасибо

Все хотят видеть. Хитрости в студию.

Да, ждем советов от Торвна по разведению тараканов на кухне и порче мат. плат утюгом.

Оно бажное, тормозное и много лет назад заброшенное. Но команд меньше, да.

Интересно, если оно всё таки смонтировалось бы, как бы оно записывалось? По порядку? На оба носителя сразу?

Необходимо использовать mergerfs.

А этим безопасно пользоваться? Вот нахомячил я туда файлов, и фоточек и конфигов десктопных и файрфоксовских профилей, а потом понадобилось второй диск вытащить, где все конфиги останутся? Боюсь, что потом придётся восстанавливать профили. Уж лучше тогда оба раздела подключать не в /home, а что-то промежуточное, /data, например, и туда складывать только фотки/фильмы/музыку, а пользовательские конфиги держать в безопасном разделе.

А ничего плохого не случится, если на ssd ext4 использовать? Но для ssd btrfs лучше?

А ничего плохого не случится, если на ssd ext4 использовать?

В теории и по словам форумчан это надёжная ФС.
На практике там куча опций монтирования указав которые можно получить самые разные эфекты, от ускорения работы до ускоренного износа диска.

Против этого настройка btrfs намного проще nossd для дисковых накопителей, ssd для твёрдотельных. (ssdspread лучше не использовать, потерь данных она не вызовет, но тормоза через несколько месяцев работы из-за неё будут, а может и псевдоисчерпание рабочего места)

К тому же у btrfs есть и другие плюшки, такие как сквозная компрессия, резервирование метаданных и субтома(очень полезно важные данные помещать на отдельный субтом, чем изолировать от части ошибок основной файловой системы).

У меня в Debian при активной записи (или чтении?) на mhddfs — наверное в несколько потоков — вылетает FUSE, так что приходится соответствующие разделы отмонтировать и монтировать заново.

Это довольно старая тулза, не исключаю что за это время появилось что-то более надежное

Не пользовался и вряд ли бы доверял такому подходу, но ТС хотел решение

Ну с такой информацией лучше покурю мануалы, чем юзать такие тулзы. Но пока у меня проблемы данной нет - так как нет ни ssd, ни жесткого

Хитрости в студию ;)

Хитростей там на самом деле не особо много, просто внимательно читаешь ман к mkfs.btrfs и посвящённый btrfs раздел в мане к программе mount.

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

Форматирование btrfs

Как и всё в линуксе лучше всего это делать в консоли так как часть опций доступна только в виде аргументов программы форматирования.

man mkfs.btrfs

Читаем ман и находим опции –data которую лучше всего поставить в single, –metadata лучше всего поставить в dup, опция –mixed скорее всего имеет значение только для механических накопителей и морально устаревших ssd, если ты готов сам следить за регулярным выполнением TRIM то можешь указать опцию –nodiscard, в опции –nodesize если будешь использовать сквозную компрессию лучше всего указать максимальное значение.

Монтирование btrfs

man 5 btrfs (цифра 5 не случайна!) или на странице в интернете читаем про опции:

• commit которую лучше всего поставить в значение 28800 , то есть в восемь часов(60608), но при этом незабывай делать тройной sync (sync && sync && sync)
• compress-force=type[:level] которую лучше всего поставть в значение zlib:6 меньше он будет при схожих временных затратах недожимать, при большем уровне сложность вычислений сильно возрастёт при том, что прирост съэкономленного объёма будет мал.
• flushoncommit поскольку предлагаемые мной настройки предполагают запись редко или при больших объёмах то лучше всего эту опцию включить, хотя при большой фрагментации она может привести к повышенному износу ячеек. В общем на твоё усмотрение, по мне так лучше после записи важных данных тройной sync делать (sync && sync && sync)
• ssd надо указать для твёрдотельных, nossd для механических накопителей,
• nossdspread надо указать, так как включение ssdspread может привести к проблемам с быстродействием фс, причём не сразу, а через месяцы эксплуатации.
• subvol= так то субтом выглядит как обычный каталог/директория, но его можно примонтировать и отдельно, что если не лень, рекомендую(мне лень)
• thread_pool= поставь в NRCPUS-2 если у тебя Бульдозер или включен гипертрейдинг и подобное.

Ещё надо учитывать то, что не все опции, например сквозная компрессия будут распространятся на субтома и для своей работы потребуют самостоятельного монтирования субтому по опции subvol или subvolid

я примерно так делал. Вот последний fstab с btrfs

nodatacow,nobarrier,ssd_spread,compress=lzo,inode_cache,commit=600

compress=lzo

А вот это ты зря, так он будет только убирать нули и делать совсем лёгкие степени сжатия.

я думал чем меньше степень сжатия, тем быстрее

Только на запись за счёт менее полного сжатия, а при чтении разницы не будет практически никакой.

Но по мне так особых причин связываться с жатием ради быстродействия нету, а вот использовать сжатие ради экономии места на носителе и ресурса ячеек стоит.
Рост же быстродействия тут только дополнительный плюс.