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