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


14

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

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

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

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

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


Обратите внимание, что снижение целостности данных будет таким же, как при использовании большинства других файловых систем, таких как ext4 или xfs, которые вообще не хранят контрольные суммы и поэтому не могут обнаружить повреждение.
basic6

1
@ basic6 Я в курсе. Отсюда и вопрос.
Андре де Миранда

Ответы:


13

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

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


Причиной может быть наличие диска без таблицы разделов. BTRFS позволяет встраивать grub / etc непосредственно в него, а XFS / EXT4 / etc - нет. Я искал файловую систему, которая бы позволяла использовать ее как CoW BTRFS поверх BTRFS, которую я использую для хранения виртуальной машины. образы не идеальны (я использую снимки и btrfs-RAID10 на хосте), и chattr + C, кажется, мой единственный вариант, кроме использования таблицы разделов. Думаю, я просто буду использовать таблицу разделов.
Алекс

5

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

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

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

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


5

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


3

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

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

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

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

Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.