> А если грамотно бэд-секторов подкинуть в неудачных местах (чего накопители делать любят) - фича пойдет лесом с интересом. И чего тогда делать? Парни из сана технично скипают этот момент.

Это вы технично передергиваете в этом моменте, а парни из Сана рекомендуют предоставить ZFS возможность контролировать уровень избыточности. Метаданные, помимо избыточности вроде зеркал или RAID-Z, хранятся в нескольких экземплярах (два или три) за счет использования дубль-блоков. Плюс, админы локалхоста могут включить дубль-блоки для своих данных даже на одном диске.

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

И потом, не будете же вы утверждать, что не существует набора неудачных бэд-блоков, которые приведут какую-нибудь ext3/ext4 в непригодное состояние?

> Много бухтя про то какое нехорошее железо, но ничего не говоря о том что делать если их допущение на котором все зиждется (что состояние ФС всегда консистентно) вдруг оказалось неверным (мало ли, левая прямая запись на диск, сбой диска, сбоящий проц или память, или хрен там знает чего еще...).

Много бухтите тут, скорее, вы. Консистентность состояния на диске обеспечивается тем транзакционностью и CoW. Если же какой-то диск в системе не обеспечивают надлежащее сохранение этих консистентных состояних, это проблема этого диска. Так что повторяем еще раз - с головой даем ZFS контролировать уровень избыточности. А также смотрим сюда:

http://mail.opensolaris.org/pipermail/onnv-notify/2009-Octob...

Опять же, надеюсь, что вы не будете утверждать, что сбоящие процессор или память не могут привести другую файловую систему непригодное состояние.