Комментарии 9
Спасибо за прекрасную статью! С удовольствием прочту продолжение. Весьма отрадно видеть освещение такой темы тут на Хабре.
Общее понимание как работает Page Cache помогает и в рутинных повседневных задачах, и в экстренной отладке на продакшене
Статья супер, но так и не понял, в каких же конкретно случаях такие знания получится применить? Есть кейсы из реального опыта?
Проблема в том, что тут очень простой код, который достаточно легко понять и протестировать, но в реальном мире на одном инстансе будет крутиться несколько контейнеров, каждый из которых по-своему работает с диском. У одного запись будет последовательная (append only log, как пример), у другого - случайное.
Ну, на пример приложение может вызвать fsync не на каждый чих, а только когда записало 4К данных
Спасибо за комментарий, если мы говорим о проде и контейнеах, а не примерах API, то да, вся ситуация намного интересней. Но, как правило, с одним файлом вы работаете из одного контейнера/cgroup'ы, у которой по хорошему, должный быть настроены все лимиты, в том числе и по IO. По сути вы в своём контейнере как будт-то одни на маашине.
В оригинале я касаюсь этих тем дальше по ходу статей. Если интерено, можете почитать оригинал
1) почему примеры на питоне, go. Вроде для таких системных вещей на старом добром С примеры бы выглядели более "естественно".
2) говоря про map() вы почти не затронули тему memory mapped files. А ведь это самое важное. Именно почему map и используют. Фактически мы получаем zero-copy где страницы самого Page cachе проецируются напрямую в пользовательские пространство, минуя копирование.
И как map() открывает в одно мгновение многогигабайтные файлы, и какие технологии за этим стоят, тоже не рассказали.
Deleted