Предположим, в памяти B+-Tree.
Есть файл index.0.full , в который записаны блоки этого B+-Tree. Откуда он взялся (курица/яйцо) пока опустим.
Он не изменяем.
Мы ходим в нашу СУБД, она подгружает какие-то блоки из index.data , большинство блоков только читаются, а какие-то блоки меняются. Если блок поменялся, он приобретает флаг "dirty" и из LRU уже выпасть не может.
Как только RAM забилась, (слишком много изменённых блоков), пишем все изменённые блоки в новый файл index.1.part и снимаем с них флаг "dirty", теперь они могут быть вытеснены на общих правах из LRU, в общем здесь можно освободить RAM как угодно.

Теперь наша СУБД смотрит на 2 "снимка":
index.0.full
index.1.part

Если какой-то блок N есть в обоих, то его валидная копия берётся из самого свежего файла, ясен пень.
СУБД живёт дальше, в какой-то момент появляется index.2.part и так далее.
Файлы .part , предположим, полностью заменяют друг друга, а не дополняют.
То есть система всегда смотрит на свежайший .full и на свежайщий .part .
При записи очередного .part, все блоки из предыдущего .part тупо копируются в новый .part.
Короче, дисковые данные этой СУБД всегда лежат в .full и .part, если блок есть в .part - читается оттуда, если его там нет, то из .full и так далее.

В какой-то момент, когда .part дорос до критического размера, мы пишем новый "полный" - index.123.full .

Короче, ни один файл на диске никогда не меняется. Ещё не дописавшийся файл имеет суффикс ".temp" и система не будет его читать, если упала в прошлый раз при попытке записать очередной файл, а догонится из бинлога.

С точки зрения админа, это суперпростая система - он может смело бекапить последние .full и .part плюс всегда растущий бинлог и не думать о том, что сейчас что-нибудь, что он копирует, изменяется. Ну и периодически дропает старые .full и .part файлы.

Чем в целом плоха такая система? Для чего, например, в InnoDB сделано НЕ ТАК, а мы хотим и изменяем .idb через double write buffer и вот это всё?

Не придётся.
Говорим хранилищу "войти в режим COW", в котором оно перед модификацией блока гарантирует, что немодифицированная копия этого блока лежит в "теневой таблице" (если его там ещё нет - делает копию и кладёт), откуда (из "теневой таблицы") наша записывалка .full и берёт блоки с бОльшим приоритетом. Таким образом, записывалка индекса всегда видит все блоки, какими они были на момент взведения атомарного флага "мы сейчас в режиме COW". После записи .full записывалка индекса снимает флаг и выкидывает теневую таблицу.

автор а что бы прочесть блок 100500, который не в кеше то нужно будет прочесть full и абсолютно все part. и так с каждым блоком не из кеша.

Таблицы блоков (индекс телефонной книги) .full и .part всегда в памяти. Мы можем глядя только на оперативу сказать, в каком из файлов .full или .part лежит самая актуальная версия блока (посмотреть в inmemory таблицу .part - если там такого блока нет, значит его надо читать из .full). Далее за одно обращение к диску читаем блок из того или иного файла.

Можете написать конкретно какая операция конкретно загнётся от ИО в какой момент? Что вы там такого по ИО собрались дикого делать с тремя копиями и зачем?

"Это" - это что именно? Я ведь описал, что как только мы забили память, мы пошли скинули всё в .part, например.
Точно так же, когда у какого-нибудь InnoDB накапливается много изменённых страниц, он бежит их куда-то там скидывать, в свой файл таблиц или бинлог (checkpoint process в Postgres).

Не тормознули. Описано ведь в стартовом посте это.

В данном посте наблюдается непонимание вообще всего.
Что за "сброс файла"? Какие конкретно "ресурсы"? Каким "локом" и что от чего изолирующим и зачем при наличии COW? Вы понимаете что такое copy-on-write в контексте первого поста и как оно в описании работает? Похоже нет.