>> Отключи ZIL и checksum и будет ZFS такая же быстрая и "надёжная"
>> на запись, как XFS, а может даже быстрее и реактивнее.
> Только потом убьется в хламинуТак XFS тоже убьётся в хламину, если рубильник дёрнуть. А ты недёргай.
> и починить нечем будет - а где у нее fsck вообще?
ZFS не нуждается в fsck, так как при обычном использовании ZIL не допускает неатомарных записей групп транзакций. То есть в случае аварийного завершения работы при последующем монтировании ФС пула происходит автоматический откат группы транзакций примерно на 5 секунд раньше неудавшейся записи. Данные остаются в непротиворечивом состоянии. Если всё же обнаружено несоотвествие контрольных сумм, то в дело вступает scrub, который производит "очистку" пула от неконсистентных данных и выводит полный поимённый список безвозвратно повреждённых и потерянных (для пула) файлов. По этому списку файлы можно восстановить из бэкапа, если требуется. Классический fsck не предоставляет такой возможности, как scrub, и сваливает найденные "остатки" файлов под незначащими именами в каталог /.lost+found — разбирайте по содержимому, что где и откуда.
> Кроме того, CoW сам по себе в принципе достаточно быстрая техника которая может показывать во многих случаях скорость
> как у обычной ФС с журналом только метаданных, обеспечивая полное журналирование.
> Что собственно и является одним из аргументов "за" такой дизайн. А
> тут слив в полтора раза...
Так называемый "слив" в полтора раза с дизайном софтверного RAID, который может конфигурироваться без остановки работы, как бы не очень серьёзный фэйл. А вот крах XFS из-за отключения питания и последующая длительная проверка fsck тома, допустим, в несколько терабайт, заставляет задуматься о смысле классических ФС на томах большого объёма.
