> Так XFS тоже убьётся в хламину, если рубильник дёрнуть. А ты недёргай.

ради интереса сколько раз дергал - не убивалась.

> ZFS не нуждается в fsck, так как при обычном использовании ZIL не
> допускает неатомарных записей групп транзакций. То есть в случае аварийного завершения
> работы при последующем монтировании ФС пула происходит автоматический откат группы транзакций
> примерно на 5 секунд раньше неудавшейся записи.

это настраивается, если чо. и тут традиционный баланс между производительностью и сохранностью данных

>Данные остаются в непротиворечивом
> состоянии.

Изя, ну что такое "данные в непротиворечивом состоянии"?

приложение пишет на диск 4кб данных. если в этот момент дернуть питание, то нет наких гарантий что после  отката данные будут на диске. чудес не бывает.

> Если всё же обнаружено несоотвествие контрольных сумм, то в дело
> вступает scrub, который производит "очистку" пула от неконсистентных данных и выводит
> полный поимённый список безвозвратно повреждённых и потерянных (для пула) файлов. По
> этому списку файлы можно восстановить из бэкапа, если требуется.

если мы делаем бэкап, тем более инкрементальный, то немалая часть возможностей zfs нам уже тут же не нужна.

> Так называемый "слив" в полтора раза с дизайном софтверного RAID, который может
> конфигурироваться без остановки работы, как бы не очень серьёзный фэйл.

если чо, softraid в linux умеет "changing the RAID level between 1, 5, and 6, changing the chunk size and  layout  for  RAID5", а в этих ваших zfs даже переезд на более объемные диски - это отдельная боль.

> вот крах XFS из-за отключения питания и последующая длительная проверка fsck
> тома, допустим, в несколько терабайт, заставляет задуматься о смысле классических ФС
> на томах большого объёма.

читайте доки, они - рулез. нет у xfs долгой проверки. fsck.xfs - это просто заглушка, она ничего не делает.