> Так 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 - это просто заглушка, она ничего не делает.
