> Действительно, но почему в таком случае ext4 в 2 раза быстрее ext2

У ext4 относительно ext2 в активе как минимум:
+экстенты.
+хэширование дир.
+delayed alloc.

И все это было явно не для красоты.

> и в 1.5 раза ext2?

Это повтор предыдущего вопроса. Я сорвал анониму стэк?
Если это было про ext3, то у ext4
+экстенты
+delayed alloc

> И ext3 в 1.2 раза быстрее ext2?

2vs3:
+хэширование дир
Может какие-то еще оптимизации которых я не помню или не знаю.

> На этот раз я использую максимально близкие к реальности цифры.

Эти цифры ... очень зависят от паттернов доступа. К ним есть разумные предпосылки в виде фич новых версий ФС.

> Кеширование интересно в контексте журнала

Не понимаю. Журнал не подлежит кешированию. Ведь если питание слетит или система ребутнется, кэш как раз и накроется. А вот журнал в этот момент как раз очень сильно понадобится. Но где ж его брать если он в кэше был? Или имеется в виду нечто типа отдельного девайса для журнала?

> и повышения производительности связанным с кешированием журнала.

...?

> Насчёт экспериментов Гулага, могу предположить, что ему выгоднее наличие битых
> файлов — если они обнаружены, это повод задавать вопросы. А внезапные
> отключения ему не грозят.

Если это про гугла - они просто все сделали иначе. Есть "распределенный алгоритм" который этим занимается. Гугловское добро не идет к ФС и не просит дать файл, оно просит распределенный алгоритм вынуть данные. Тот делает запрос к какому-нибудь серверу из подходящих. Тот отдает данные. Или не отдает. Или отдает битые. В первом случае ок, в втором и третьем запрос будет повторен на какой-нибудь другой сервер.

Такие вещицы могут оперировать даже не чексуммами а скорее хэшами и это не только чексум но и способ адресации. Основы таких штук гуглятся по словам типа content addressable network. Где-то рядом можно познакомиться с каким-нибудь ipfs...