Причина розміщення зображень віртуальних дисків у файловій системі BTRFS

Я читав про BTRFS та ZFS деякий час, і хоча я ціную переваги CoW при розміщенні важливих файлів, на даний момент я спантеличена такою дилемою:

Зважаючи на те, що ZFS і BTRFS, схоже, зазнають погіршення продуктивності при розміщенні великих файлів, що підлягають випадковому запису (наприклад, QCOW2, VDI тощо), чому б хтось використовував BTRFS як FS за вибором для розміщення VM?

Я знаю, що у випадку o BTRFS ви можете вибірково відключити CoW за допомогою chattr або опції кріплення nodatacow, зменшуючи деградацію, накладену фрагментацією та CoW ...

Однак, за словами Redhat, це також "відключає перевірку контрольної суми даних та метаданих, що призводить до зниження цілісності даних". (крім втраченого стиснення і, природно, так бажаного КВ).

Виходячи з цього, я запитую: Чому хтось обрав BTRFS за скажімо, XFS над LVM над MD RAID?

Якщо основним випадком використання є зберігання VM-зображень або баз даних, і ви не зацікавлені у прийнятті потенційних проблем з роботою, щоб отримати переваги цілісності даних btrfs, то я не можу придумати жодної причини, чому ви хочете вибрати btrfs над xfs або ext4

Вимкнення функції копіювання при записі лише для каталогу зображень VM (з використанням chattr + C) є найбільш актуальним, коли зберігання зображень VM - лише одне з багатьох застосувань для вашої файлової системи. Тоді може бути дуже зручно просто відключити копіювання при записі для цього єдиного каталогу, але все ще зберігаючи всі переваги btrfs для решти файлової системи.

BTRFS має різний формат диска, який буде перевершувати інші файлові системи в деяких шаблонах запису. Зокрема, було витрачено багато зусиль на покращення того, як мета-дані записуються на диск, і вони підтримують деякі вдосконалені функції, такі як контрольна сума, стиснення та знімки. Для великих файлів підвищення продуктивності метаданих, як правило, не важливо.

У порівнянні з ZFS, BTRFS є більш простим рішенням і краще підтримується в Linux. Основний мінус полягає в тому, що він також не масштабується (при додаванні великої кількості дисків) і не має однакових функцій.

Порівняно з XFS це рішення буде нижчою продуктивністю. Тобто знадобиться більше процесорного часу, щоб записати фрагмент даних на диск, і це буде обмежено максимальною пропускною здатністю. Це можна певною мірою пом'якшити, виконуючи такі дії, як відключення перевірки контрольної суми, але тоді ви втрачаєте основну перевагу BTRFS над XFS, що є покращеною інформацією про метадані. Тобто контрольна сума та різні журнали (що може бути краще в деяких ситуаціях).

Що стосується підтримки Copy On Write (COW), XFS надає перевагу продуктивності, ніж суто COW. Тобто XFS має дуже хороші метадані та журнальні функції з точки зору масштабованості, і вони, як правило, не перезаписують файлові дані при записі, за винятком того, що це дозволить перезаписати наявні дискові блоки, якщо програма спеціально вимагає перезаписати ці дані . Це може бути добре у випадку з VM, оскільки ваш розподіл диска спочатку може бути суміжним, і в такому випадку він залишатиметься суміжним протягом життя VM.

Використовуючи BTRFS, навіть за допомогою nodatacowподібних даних ви все ще можете створювати знімки даних вручну з CoWповедінкою, тому це швидко і не вимагає багато пам’яті. Крім того, ці знімки є більш гнучкими, ніж використання LVM, оскільки вам не потрібно резервувати простір під файловою системою, про яку файлова система не знає і не може бути використана, якщо вона взагалі не потрібна. Як і у ZFS, знімки можна надсилати та отримувати по мережі, що може допомогти вам покращити стратегію резервного копіювання. Тож навіть nodatacowBTRFS, здається, перевершує використання LVM.

Після роботи з платформами хмарних обчислень я прийшов прийняти їхній погляд на віртуальні машини як на контейнер для даних та функціональності, де власне vm має менш важливе значення.

Я вважаю за краще мати гарне резервне копіювання та відновлення та встановлення-розгортання на місці та менше турбуватися про цілісність VM та більше про продуктивність.

Тобто для JFS / XFS / EXT4 над LVM через MD-рейд, а не BTRFS. Переконайтеся, що я ніколи не зберігаю нічого, що не створюється резервна копія на VM протягом більш тривалого періоду часу ... і майте сценарії та процедури, щоб отримати нову інсталяцію VM в розумний час, якщо щось станеться.

Але це скоріше сценарій розробки / експерименту, ніж будь-що інше.