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

Question

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

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

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

Однако, согласно Redhat, это также «отключает проверку контрольных сумм данных и метаданных, что приводит к снижению целостности данных». (в дополнение к потерянному сжатию и естественно так желаемому CoW).

Исходя из этого, я спрашиваю: почему кто-то выбрал BTRFS, скажем, XFS, а не LVM, а не MD RAID?

Answer 1

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

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

Answer 2

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

По сравнению с ZFS, BTRFS является более простым решением и лучше поддерживается в Linux. Основным недостатком является то, что он также не масштабируется (при добавлении большого количества дисков) и не имеет того же набора функций.

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

С точки зрения поддержки копирования при записи (COW), XFS предпочитает производительность, а не только COW. Т.е. XFS имеет очень хорошие метаданные и функции ведения журналов с точки зрения масштабируемости и, как правило, не перезаписывает данные файла при записи, за исключением того, что это позволит перезаписывать существующие блоки диска, если приложение специально запрашивает перезапись этих данных. Это может быть полезно в случае виртуальной машины, так как первоначально выделение диска может быть непрерывным, и в этом случае оно будет оставаться непрерывным в течение всего срока службы виртуальной машины.

Answer 3

Используя BTRFS, даже с nodatacow и т.д. Вы по-прежнему можете создавать моментальные снимки данных вручную с поведением CoW , так что это быстро и не занимает много памяти. Кроме того, эти снимки более гибкие, чем при использовании LVM, поскольку вам не нужно резервировать пространство под файловой системой, о котором файловая система не знает, и не может использоваться, если вообще не требуется. Как и в ZFS, снимки можно отправлять и получать по сети, что может помочь вам улучшить стратегию резервного копирования. Так что даже с nodatacow BTRFS, кажется, превосходит LVM.

Answer 4

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

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

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

Но это скорее сценарий разработки / эксперимента, чем все остальное.