>> Твой винт поддерживает хотя бы дедупликацию блоков ФС
> Мммм... трудновато найти мазохиста, готового платить за дедуп 4+ кратным падением производительности.

А чего же тогда лезет в охотный ряд и сравнивает в принципе известные факты: "дедупликация тормозит", "обеспечение журналирования и данных и метаданных тормозит". Капитан Очевидность для тех кто в курсе, а для тех, кто не в курсе, герой-срывающий-покровы-с-гадкой-и-тормозной-технологии?

>> не говоря уж о сквозной целостности данных и метаданных?
> Ты не поверишь - твоя система также не имеет никакой "сквозной целостности".
> Сбой памяти/контроллера памяти/CPU угробит твою FS еще до расчета CRC, и
> вся твоя целостность пойдёт лесом.

При сбое любого компонента на пути данных ZFS пул немедленно завершает свою работу. Это сделано намеренно, чтобы не разрушить пул окончательно.

>> Тогда включи хотя бы журналирование _данных_и_метаданных_ в своей Ext4
> Лично мне нужно только журналирование метаданных. Включать журнал данных имеет смысл только
> там, где действительно нужна целостность рабочего набора. В общем же случае
> рабочий набор при сбоях перестраивается из долгосрочного.

Ну а в ZFS свойство checksum для данных можно перевести в состояние "off" и избавиться от проверки данных на лету. Что случится в этом случае с быстродействием? Быстродействие вырастет незначительно, так как эта вещь хорошо оптимизирована.

А что с механизмом журналирования данных в Ext3/4? Тут производительность I/O гуляет в весьма широких пределах в зависимости от того, включен он или выключен, так как эта ФС не проектировалась как CoW-only. Но если вы хотите сравнивать сравнимые вещи, то, пожалуйста, задействуйте этот механизм в своей любимой ФС и тогда сравнивайте с ZFS. А то можно сравнить сжатие потока нулей из /dev/zero с потоком MP4 и внезапно удивиться, что нули-то жмутся сильнее и быстрее!