Или 3. Одного восстановил - два других проебал.

Штуки 3 встречал, ничего не чинилось, даже если смонтировать fs половины файлов нет или открываешь его, а там мусор вместо данных

наш опыт из внутреннего чатика

Под нагрузкой вырубилось питание? Или рандомно умерло?

Рандомно, но кейс с питанием крайне редкий, гипервизоры в Tier3 цоде.

Могли ноду поребутить только сами, если ssh не живой.

zfs - специально мучал - вырубал при scrub, при интенсивной записи, при восстановлении из снапшота, при send/receive, при создании больших и мелких файлов, при рандомном чтении/записи произвольными блоками, при выбивании zil или cache из под  нагруженной zfs - во всех случаях удавалось поднять данные с последней валидной транзакции. Были случаи когда fs не могла загрузиться, но в режим readonly всегда можно было зацепиться на последнюю успешную транзакцию и скопировать данные в новый пул. Но всё это случаи до 50TB. Случаи с объёмами в петабайт не было возможности проверить. В эксплуатации zfs 5 лет на 12 хостах.

ну сетап в студию, какие диски, какие конфиги :)

в зфс есть несколько опций, которые позволяют себе стрельнуть в ногу :)

dd везде есть.

Конфиги дефолт со сжатием lz4, options zfs zfs_arc_max=53687091200

файлы имаджей vm qcow2 бытые становятся

у нас много где на хостах в качестве корневого раздела даже, но образы виртуалок ебаются

где тут можно стрельнуть в ногу?

низя для qсow сжимать, надо было zvol и raw

какие версии, какие параметры у zfs крутили

если бы у всех на дефолте стреляло бы - давно бы шум поднялся

только если баг на uncommon конфиге поймали

выключали ли сжатие в arc, там есть место для багов, т.к. уже не дефолт

какие настройки кеширования io ставили? мб там и стрельнули себе в ногу, очень на это похоже