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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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