Должен ли я использовать ZFS внутри виртуальной машины? По имеющейся информации (в частности эта тема, которые я процитирую ниже) это не лучшая идея, если не предусмотрены определенные меры (например, использование VT-d). Основная проблема якобы заключается в том, что гипервизор может сообщить о блоке, который должен быть записан, хотя на самом деле он еще не был написан. Предположительно ZFS особенно чувствительна к такому несоответствию по сравнению с другими файловыми системами:
Специфика того, почему это так плохо, связана с дизайном без fsck.
В ходе этого обсуждения также было признано, что:
Единственный сценарий, в котором «указатель, записанный перед данными» превращается в «указатель записан, но нет данных», - это, насколько я могу представить, по-прежнему происходит сбой ОС или гипервизора.
Но каковы наихудшие последствия в случае такой аварии?
Возможно ли какое-то тихое повреждение, которое не может быть обнаружено с помощью скраба?
Я попытался смоделировать сбой, используя VirtualBox и выбрав Close / Power Off, когда данные были записаны в ZFS внутри виртуальной машины. Я проделал это примерно 20 раз, но не смог обнаружить никаких проблем. Возможно, этот метод тестирования не подходит. Есть ли лучшие способы поэкспериментировать с этим?
Практически любой современный гипервизор (VMWare, Xen, KVM, HyperV, даже VirtualBox) поддерживает прохождение барьера: когда виртуальная машина явно сбрасывает что-то на диск (путем выдачи барьера / FUA), гипервизор передает барьер на хост, заставляя те же сбросы, выполняемые гостевой ОС. Другими словами, никаких повреждений не ожидается для важных / длительных записей (как та, которая используется самой файловой системой для обновления своих метаданных).
Хотя большинство гипервизоров можно настроить так, чтобы они игнорировали сбросы, это может поставить под угрозу любой файловые системы - XFS, EXT4 и т. д. будут подвержены серьезным повреждениям не меньше, чем ZFS.
Вернемся к основному вопросу: использовать ZFS в гостевой ОС совершенно безопасно, и у меня есть личный опыт подобной настройки. Это позволит гостю использовать расширенные функции, такие как сжатие, моментальные снимки и отправка / получение. Однако это может привести к несколько более низкой производительности гостевой системы (ZFS не предназначена для использования в качестве файловой системы, победившей в тестах). Более того, поскольку многие сети SAN реализуют одни и те же функции на уровне образа диска, вам следует оценить, стоит ли влияние на производительность из-за двойного CoW дополнительной гибкости на уровне гостя.
По причинам, указанным выше, я обычно использую ZFS на уровне образа диска / гипервизора, а XFS или EXT4 использую внутри самих виртуальных машин. Однако в сценарии, когда у меня нет видимости базового SAN / хранилища (и его политик моментальных снимков / сжатия / репликации), я иногда использую ZFS на гостевом уровне.
В этих случаях добавленные функции более чем компенсируют влияние на производительность по сравнению, например, с простой настройкой XFS. И вообще никаких проблем со стабильностью / долговечностью.
Примечание: VT-d полезен только в том случае, если вы планируете передавать необработанные диски (или другие аппаратные устройства) самому гостю. Если вы используете виртуальный диск на основе файла или тома, вы не используете VT-d.