Page cache и fsync: почему «записали» и «не потеряется» — разные утверждения

Что здесь на самом деле спрашивают

Лестница обычно такая:

1. «Что делает write?» — разминка, на которой выясняется, думает ли собеседник, что данные ушли на диск.
2. «Данные потеряются, если процесс упадёт сразу после write?» — здесь начинается содержание.
3. «А если упадёт машина?» — тот же вопрос, другой ответ, и разница объясняет весь механизм.
4. «Чем fsync отличается от fdatasync?» — знаете ли вы, что различаются они метаданными.
5. «Почему база данных не делает fsync на каждую запись?» — вопрос про цену.
6. «Достаточно ли fsync файла, чтобы файл точно существовал?» — вопрос, где долговечность содержимого и долговечность имени расходятся.

Числа получены прогоном bench/durability/fsync.py и bench/durability/practice.py. Времена зависят от диска сильно: у вас будут другие. От машины не зависят наблюдения: что переживает падение процесса и что обещает каждый вызов.

База: где данные после того, как запись вернула успех

Прежде чем говорить о кеше и о сбросе, стоит назвать обычными словами путь, по которому идут данные. У него четыре участка:

1. приложение вызвало запись — передало ядру кусок памяти и сказало, в какой файл его положить;
2. память ядра — данные приняты и лежат в области, которой распоряжается ядро; вызов на этом возвращается;
3. файловая система — она решает, куда именно на устройстве эти байты лягут и какие служебные записи при этом надо поправить;
4. устройство хранения — то место, где байты остаются, когда питания нет.

Ключевое здесь — на каком участке заканчивается вызов записи. Он заканчивается на втором, а не на четвёртом: приложение получает успех, когда данные приняло ядро, а не когда их принял диск. Дальше их несёт ядро — само, в своём темпе, и приложение при этом ничего не ждёт и ни о чём не узнаёт.

И вот главный вопрос урока: запись вернула успех — где на самом деле данные? От ответа зависит всё остальное: что с ними случится, если сейчас умрёт процесс, что случится, если пропадёт питание, и во что обходится требование, чтобы они уже точно были на устройстве.

Короткий ответ такой: данные в памяти ядра. Эта память общая — она не принадлежит записавшему процессу и переживает его смерть. Но она же и исчезает вместе с питанием, поэтому «данные приняты» и «данные устойчивы» — два разных утверждения, и второе нужно просить отдельным вызовом.

Этого уже достаточно, чтобы ответить на базовый вопрос собеседования. Всё дальнейшее — про то, сколько стоит этот отдельный вызов, чем различаются два его вида и почему базы данных требуют подтверждения не на каждую запись.

Механизм 1: write доводит данные до кеша, а не до диска

Начнём с того, что write(2) говорит о себе прямо:

Обратите внимание на вторую половину: ошибка может прийти позже, и прийти она может в close. Это первое практическое следствие: код, который игнорирует результат close, теряет ошибки записи молча.

Что делает write на самом деле — переносит данные в page cache, кеш страниц файлов, живущий в памяти ядра. Оттуда их когда-нибудь вынесет на диск фоновая запись ядра; когда именно, приложение не знает и не решает.

И раз кеш — это память ядра, привычка «закрыл файл, значит сохранил» тоже не имеет оснований, о чём close(2) говорит отдельно:

Механизм 2: падение процесса и потеря питания — разные события

Самый полезный вопрос темы: если данные ещё не на диске, что их теряет? Проверяем самым грубым способом. Процесс пишет в файл, fsync не зовёт — и получает SIGKILL, то есть умирает без единой строки уборки:

2. WHOSE MEMORY THE PAGE CACHE IS
---------------------------------
  child wrote without fsync, then SIGKILL      exit -9
  file content after the kill                  survived the kill

exit -9 — так о смерти по сигналу сообщает subprocess: отрицательное число здесь и есть номер сигнала. Оболочка на том же месте напечатала бы 137, то есть 128 + 9 (урок про сигналы).

Данные на месте. Более того, их видит другой процесс: bench/durability/practice.py печатает содержимое файла дважды — глазами того, кто прочитал его после смерти автора, и глазами постороннего процесса. Обе строки одинаковы, потому что чтение идёт через тот же кеш.

Отсюда различение, которым стоит отвечать:

• Падение процесса не теряет ничего, что дошло до write. Кеш переживёт и падение, и убийство, и OOM-killer.
• Потеря питания — другое дело: данные, ещё не ставшие устойчивыми, при ней могут быть потеряны, потому что память, в которой кеш и жил, выключается вместе с машиной.

Обратите внимание на «могут быть». Гарантии, что несброшенное уцелеет, нет никакой; гарантии, что оно непременно пропадёт, тоже нет — часть страниц ядро могло вынести на устройство фоновой записью раньше, и какие именно, приложение не знает. Планировать на этом нельзя: с точки зрения приложения всё несброшенное — это данные, о судьбе которых после отключения питания ничего не известно.

Именно поэтому «у нас всё в порядке, приложение просто перезапустилось» — честная фраза, а «у нас всё в порядке, машина просто перезагрузилась» — нет.

Механизм 3: что обещает fsync и сколько это стоит

Обещание записано в fsync(2):

Цена этого обещания и есть главное измерение урока:

1. THE PRICE OF DURABILITY, PER WRITE
-------------------------------------
  write only (4 KiB), median                   1.4 us
  write + fdatasync, median                    142.9 us
  write + fsync, median                        143.9 us
  fsync over plain write                       104x
  gap between fsync and fdatasync              0.9 us
  run-to-run spread of the same mode           51.1 us
  difference resolvable on this machine        no

Этот блок снят прогоном bench/durability/fsync.py. В задачах ниже цитируется второй прогон, bench/durability/practice.py: там та же пара получилась 1,8 и 164,7 мкс, а кратность — 90,1. Два прогона на одной машине расходятся именно так, как обещает строка run-to-run spread: содержателен порядок кратности, а не её цифра.

Две вещи в этом блоке важны по-разному.

Кратность — содержательна. Сотня раз: столько стоит разница между «данные в памяти ядра» и «данные на устройстве». Это не свойство Linux и не недоработка, а физика: во втором случае в дело вступает устройство и его подтверждение.

Разница между fsync и fdatasync — не различима здесь, и скрипт это печатает сам. Разрыв 0,9 мкс при разбросе 51,1 мкс между повторами одного и того же режима: скрипт меряет каждый режим пятью кругами, и это строка run-to-run spread of the same mode. Заявлять кратность в такой ситуации нельзя, и последняя строка блока, difference resolvable on this machine, говорит no. Различие между вызовами при этом реальное и записано в документации:

То есть fdatasync экономит на записи метаданных — и выигрыш появляется там, где эти метаданные дороги: при росте файла, на файловых системах с журналом метаданных, на медленных устройствах. На виртуальном диске этого контейнера экономия утонула в разбросе, и честный ответ здесь — «не измерено», а не «одинаково».

Механизм 4: почему база данных не делает fsync на каждую запись

Кратность из прошлого блока — это цена одного обещания. Дальше вопрос арифметики: сколько раз его требовать.

3. ONE FSYNC FOR MANY RECORDS, OR ONE EACH
------------------------------------------
  100 records, fsync after each                17.2 ms
  100 records, one fsync at the end            1.0 ms
  ratio                                        17x

Байты те же, диск тот же, и после последней строки данные одинаково долговечны в обоих случаях. Разница — в числе точек, в которых мы потребовали подтверждения.

Отсюда групповая фиксация, которую в базах называют group commit: транзакции, пришедшие почти одновременно, ждут общего сброса. Каждая ждёт дольше, чем ждала бы в одиночку, но одна задержка обслуживает всю группу, а не каждую транзакцию по отдельности.

И отсюда же ответ на вопрос «почему нельзя просто делать fsync на каждый запрос»: можно, и это будет корректно. Цена — та самая кратность, помноженная на число запросов, и она превращается в предел пропускной способности.

Глубже: имя файла живёт не в файле

Последняя ступень — про место, где долговечность содержимого и долговечность имени расходятся. Вы создали файл, записали, вызвали fsync, машина упала. Гарантированно ли файл существует?

fsync(2) отвечает недвусмысленно:

4. WHAT FSYNC IS FOR: THE FILE, NOT THE DIRECTORY
-------------------------------------------------
  file synced                                  yes
  directory sync cost                          0.11 ms

Замер здесь отвечает не на вопрос «нужен ли сброс каталога» — на него отвечает документация, — а на вопрос «сколько он стоит».

Содержимое файла и факт его существования под этим именем — два разных объекта, и синхронизируются они отдельно. Отсюда обязательная последовательность для атомарной замены файла, которую и спрашивают: записать во временный файл, сбросить его, переименовать поверх целевого, сбросить каталог. Пропуск последнего шага — это код, который работает до первого отключения питания и теряет ровно то, что считал записанным.

Как отвечать на собеседовании

Короткий ответ: write доводит данные только до кеша ядра и возвращается; долговечность обещает fsync, и стоит она на два порядка дороже. Поэтому падение процесса не теряет записанного — кеш принадлежит ядру, — а при потере питания всё несброшенное может быть потеряно.

Этого достаточно, чтобы ответить верно. Дальше — то, что добавляют, если собеседник копает.

Если интервьюер копает глубже

Хороший ответ отличают три вещи. Первая — вы различаете две аварии: смерть процесса и отключение питания, и говорите, почему ответ разный. Вторая — вы называете цену числом и знаете, что из неё следует: групповая фиксация существует не ради красоты, а потому что сброс на каждую запись упирается в устройство. Третья — вы помните про каталог: fsync файла делает долговечным содержимое, а не имя, и при атомарной замене файла синхронизировать нужно оба.

И одна аккуратность в формулировке, которую замечают. «Падение машины теряет данные» — слишком сильно сказано: правильно говорить, что данные, ещё не ставшие устойчивыми, при потере питания могут быть потеряны. Часть их ядро могло успеть вынести фоновой записью, и какая именно часть — приложению неизвестно. Практический вывод от этого не меняется, а вот утверждение становится верным: на несброшенное нельзя рассчитывать ни в одну, ни в другую сторону.

Дальше спросят

Частые заблуждения

Практика

Две задачи. Сначала ответьте, потом сверьтесь с настоящим выводом: в обеих правильный ответ взят из прогона скрипта, а не назначен.

print(content_after_kill(path) or "(empty)")
print(seen_by_another_process(path) or "(empty)")

survived the kill
survived the kill

survived the kill
(empty)

(empty)
(empty)

(empty)
survived the kill

Проверка знаний