> В COW тоже накладные расходы высокие. При изменении файла, он еще и
> копируется в другое место.Никуда там файл не копируется. При записи изменений:
1) В сторонку пишется блок с этими самыми изменениями, по количеству оных.
2) Структуры ФС описывающие размещение файла меняются чтобы указывать что теперь вон тот кусок файла брать надо вот там, а не там где было раньше. Собственно операция записи измененного куска и есть то "копирование".
Bonus 1: поскольку старое содержимое никто не сносил, на него в принципе можно вернуться. Этакая машина времени - условно нахаляву. Достаточно вернуть описание размещения файла в старый вид и готово: у вас получается старый вариант файла.
Bonus 2: в принципе подвид этой техники можно применить и к самим структурам ФС, так что в результате будет ну совсем просто городить снапшоты - для них всегда все и так есть, достаточно лишь зафиксировать консистентное состояние и объявить что "а вот это - типа снапшот". При этом действий по его созданию минимум: все структуры потребные для этого и так уже были, осталось только формально задекларировать и сделать пометочку, чтоб GC это не подгреб при случае как нечто "устаревшее".
Из недостатков этого подхода:
1) Очевидно что линейный доступ к такому файлу превратится в нелинейный. В принципе эта схема более склонна к фрагментации. На механических дисках сие может икаться.
2) Без принятия специальных мер место на томе рано или поздно закончится. Поэтому требуется Garbage Collector. Который однажды придет и грохнет тот перезаписанный блок в середине файла, пометив его как "пустое место которое можно использовать", так что старая версия "перестанет существовать". В принципе, оный может быть совмещен с дефрагером, избавившись от первой проблемы, т.к. логично было бы и вдвинуть как раз "скопированный" фрагмент в "только что получившееся пустое место" (если конечно оно туда лезет). В btrfs примерно так и делают IIRC.
> Я так понял, в ext4 журналируются только или в основном метаданные.
В дефолтной настройке большинства дистров - только метаданные. Если вы хотите еще и данные, такая опция есть. Но вам не понравится скорость работы. Это для тех кому транзакционная модель важнее всего остального, любой ценой.
> По данным гугля это съедает 20% скорости. Сам гугль отказался от журналирования
> в чего-то редового, об этом писали.
А гугль вообще особый случай. Понимаете, им вообще глубоко плевать - в их распределенной структуре один узел может не то что сбойнуть, а выгореть синим пламенем. Никто и не заметит что там что-то не так: данные есть и на иных узлах, они подхватят нагрузку и как будто бы ничего и не умирало. А у вас тоже есть такая крутая распределенная ФС, что вы можете спокойно наплевать вообще на вылет парочки компьютеров в распределенном сторадже? :)
