Unionfs vs Aufs vs Overlayfs vs mhddfs, яким я користуюся


15

Я випадково читав про файлову систему об'єднання, яка дозволяє користувачеві одночасно монтувати декілька файлових систем один на одного.

Однак я знаходжу проблеми, коли вирішувати, який з них використовувати (Unionfs vs Aufs vs Overlayfs vs mhddfs) і чому я ніде не знайшов конкретної інформації з цього приводу. Я знаю, наприклад, що overlayFS був прийнятий в основному ядрі Linux, що означає, що він може отримати ширше прийняття. Буду вдячний, якщо хтось дасть мені певну перспективу.

Крім того, я не можу знайти жодного задуманого випадку використання для файлової системи Union через щось на кшталт LVM (як рекомендують користувачі в окремому запитанні ) або налаштування RAID, за винятком того, що LVM вимагає форматування всіх накопичувачів, що може бути небажаним, якщо ви вже мають цінні дані про накопичувачі.


Більш загально, я все ще чекаю відповіді на unix.stackexchange.com/questions/282393/union-mount-on-linux
"SO- перестань бути злим"

Відповіді:


4

Ось декілька думок - я все ще вивчаю це і оновлю це, коли я піду.

Як вибрати файлову систему об'єднання

Є два способи подивитися на це:

  • Як порівнюють особливості кожного?
  • Для деяких випадків поширеного використання, який я повинен вибрати?

Я порівняю unionfs / unionfs-fuse / overlayfs / aufs / mergerfs, останній замінить mhddfs.

Особливості кожного

Статус розвитку

Підтримка дистрибуції / ядра

Існують файлові системи режиму ядра та користувальницькі режими, останні працюють на FUSE. У режимах ядра є менші накладні витрати (є накладні витрати, коли код перемикається між простором користувача та простором ядра), але єдиний, який зараз підтримується в ядрі Linux, - це накладення . Файлові системи користувальницького режиму простіші для розповсюдження в пакет.

  • unionfs та aufs потребують патчів ядра
  • Unionfs не поширюється Debian (решта -)
  • unionfs-fuse та mergerfs засновані на FUSE, тому не потрібно додаткові модулі в ядрі
  • overlayfs є частиною ядра з 3.18 (Debian Stretch)

Копіювати при написанні

Це стосується нижчого випадку використання Live CD:

  • mergerfs не має копії під час запису
  • Інші роблять

Використовуйте випадки

Корінь лише для читання / випадок використання Live CD

Ідея полягає у тому, щоб мати компакт-диск / розділ для Linux, доступний лише для читання. Файлова система об'єднання змушує користувача виглядати так, як це система читання-запису, щоб вони могли вносити зміни. Існує файлова система читання-запису (наприклад, RAM-диск tmpfs), яка зберігає "Delta" будь-яких змін, внесених користувачем, але не повний знімок.

Тут будь-яка файлова система об'єднання зробить.

Справа використання Докера

Я знаю, що це головний випадок використання, але не знаю деталей - чи може хтось надати рекомендації щодо цього?

Об'єднання жорстких дисків

Наприклад, у вас можуть бути два набори /homeкаталогів у різних файлових системах. Або ви можете оновити домашній комп'ютер за допомогою другого жорсткого диска і хочете отримати один логічний том.

Тут ви насправді не хочете копіювати при записі, тому, можливо, злиття є найкращим вибором.

Файлова система об'єднання проти LVM для об'єднання дисків

Я перерахую кілька випадків використання, які можна досягти за допомогою файлових систем об'єднання, але не LVM:

Якщо ви оновлюєте існуючу систему за допомогою другого диска, щось на зразок злиття може бути кращим, оскільки LVM вимагатиме від вас переформатувати перший жорсткий диск, отже, зберігаючи дані на ньому. Файлова система об'єднання дозволила б уникнути цього кроку.

LVM може розділити файл на два фізичних жорстких диска (якщо вважати RAID 0), тож ви втратите його, якщо один жорсткий диск вийде з ладу.

Деякі користувачі можуть, наприклад, зберігати свій /homeкаталог на USB-накопичувачі, який вони можуть забрати.

У випадку використання одного віртуального розділу на двох фізичних дисках, з LVM вам не потрібно буде турбуватися про збереження файлів на одному чи іншому диску. За допомогою mergefs система може автоматично вибрати, який саме для вас, залежно від кількості вільного місця.


Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.