Почему данные не пропадают при отключении питания во время сохранения: инженерия согласованности при сбоях (Crash Consistency)

1. Введение: минное поле внутри добавления одного блока данных в 4 КБ

Когда вы нажимаете Ctrl+S в текстовом редакторе или подтверждаете банковский перевод, ваше приложение вызывает системный вызов write(). С точки зрения прикладного программиста сохранение файла выглядит как одно мгновенное, неделимое (атомарное) действие.

Однако внутри ядра операционной системы, файловой системы, движка базы данных и контроллера SSD скрывается одна из сложнейших проблем системного программирования — проблема согласованности при сбоях (Crash Consistency Problem).

Рассмотрим простейшую операцию в классической файловой системе UNIX (например, UFS или ext2): добавление одного нового блока данных размером $4\,\text{КБ}$ ($D_{\text{new}}$) в конец существующего файла. Даже эта тривиальная операция требует обновления как минимум трёх физически разнесённых структур на носителе:

Битовая карта данных (Data Bitmap $B$): изменить бит для физического блока $k$ с $0$ (свободен) на $1$ (занят).
Индексный дескриптор (Inode $I$): обновить метаданные файла — увеличить размер size, обновить время модификации mtime и записать физический адрес блока $k$ в массив указателей inode.
Сам блок данных ($D_{\text{new}}$): записать реальные $4\,\text{КБ}$ пользовательских данных в физический сектор блока $k$.

Здесь мы сталкиваемся с фундаментальной физической асимметрией оборудования: оперативная память (DRAM) быстра, но энергозависима (volatile), тогда как диски и NAND-флеш SSD энергонезависимы (non-volatile), но физически не способны обновить три разнесённых блока $(B, I, D_{\text{new}})$ одновременно в рамках одной атомарной операции. Если питание пропадёт посередине этих трёх записей ($2^3 - 2 = 6$ состояний частичной записи), после перезагрузки файловая система окажется в состоянии критического разрушения:

Записано на диск	Потеряно в RAM	Возникающая несогласованность и степень опасности
Только $D_{\text{new}}$	$B,\; I$	Безопасная потеря данных: данные лежат на диске, но ни inode, ни битовая карта на них не указывают. Целостность файловой системы не нарушена.
Только $B$	$I,\; D_{\text{new}}$	Утечка пространства (Space Leak / блок-сирота): блок $k$ помечен занятым ($1$) в $B$, но ни один файл на него не ссылается; ёмкость потеряна навсегда.
Только $I$ (или $I + D_{\text{new}}$)	$B$	Двойное выделение (Double Allocation — катастрофическое разрушение): inode $I$ указывает на блок $k$, но битовая карта $B$ считает его свободным ($0$). Позже другой файл займёт блок $k$, и оба файла уничтожат данные друг друга!
$I$ и $B$	$D_{\text{new}}$	Утечка чужих старых данных (Stale Data Exposure — критическая уязвимость): inode и битовая карта обновлены, но $D_{\text{new}}$ не записан. Чтение файла вернёт чужие удалённые данные (пароли, приватные ключи), ранее лежавшие в секторе $k$!

2. Почему записи попадают на диск не в том порядке, в котором их отправила программа

В современной компьютерной архитектуре хронологический порядок вызовов write() почти никогда не совпадает с порядком физической записи битов на магнитные пластины или ячейки NAND из-за четырёх уровней энергозависимой буферизации и переупорядочивания (Reordering):

  flowchart TD
    APP["1. Пространство пользователя<br/>Буферы времени выполнения (stdio fwrite) / Буферный пул СУБД"]
    PC["2. Страничный кэш ядра ОС (Page Cache / Dirty Pages)<br/>Отложенная запись (Write-Back): объединяет и задерживает запись на секунды"]
    SCHED["3. Блочный уровень ОС и планировщик ввода-вывода (mq-deadline / BFQ)<br/>Сортирует запросы по LBA-адресам для минимизации времени поиска"]
    DEV["4. Бортовой энергозависимый DRAM-кэш диска и очереди NCQ/NVMe<br/>Контроллер FTL в SSD переупорядочивает запись между каналами NAND"]
    MEDIA[("5. Энергонезависимый физический носитель<br/>Ячейки NAND Flash / Магнитные пластины (Только это переживает сбой питания!)")]

    APP -->|"Системный вызов write()"| PC
    PC -->|"Фоновый сброс / fsync()"| SCHED
    SCHED -->|"Команды NVMe / SATA"| DEV
    DEV -->|"Аппаратный барьер FLUSH CACHE / FUA"| MEDIA

Чтобы гарантировать порядок и долговечность, ОС должна явно отправлять аппаратные барьеры сброса кэша (NVMe Flush, SATA FLUSH CACHE EXT или бит FUA: Force Unit Access), заставляющие накопитель сбросить свой бортовой DRAM-буфер в энергонезависимые ячейки NAND.

3. Поколение 1: Оптимистичное обновление на месте, `fsck` и Soft Updates

fsck (File System Consistency Check) и предел масштабируемости: Ранние файловые системы UNIX (FFS, ext2) устраняли несогласованность после сбоя путём полного сканирования всех inode, битовых карт и каталогов перед монтированием (fsck). Поскольку время работы fsck пропорционально общей ёмкости диска $O(N_{\text{disk}})$, проверка современного многотерабайтного массива занимает часы или дни простоя — даже если в момент отключения питания изменялся один-единственный файл размером $4\,\text{КБ}$!
Soft Updates (Ganger & McKusick, 1994): Применявшийся во FreeBSD UFS механизм обходился без журнала за счёт строгого отслеживания графа зависимостей указателей в памяти и разрыва циклических зависимостей внутри одного блока с помощью временного отката (roll-back) и наката (roll-forward) отдельных полей в ОЗУ перед записью на диск.

4. Основа современных хранилищ: упреждающее протоколирование (WAL) и журналирование

Чтобы сократить время восстановления с $O(N_{\text{disk}})$ до объёма активных транзакций в момент сбоя $O(N_{\text{active}})$ (считанные миллисекунды!), файловые системы (ext3/ext4, XFS, NTFS) и СУБД используют упреждающую запись в журнал (Write-Ahead Logging, WAL / Journaling):

Journal Write: перед изменением основных областей диска (Home Locations) система последовательно добавляет в кольцевой Журнал (Journal) дескриптор начала транзакции TxB (с номером TID) и обновлённые копии блоков $(I, B, D_{\text{new}})$.
Journal Commit (Точка атомарной фиксации): после аппаратного барьера сброса кэша записывается единственный сектор — блок фиксации TxE (Transaction End). Запись этого единственного сектора TxE является атомарным переключателем, фиксирующим всю транзакцию!
Checkpoint: после записи TxE блоки $(I, B, D_{\text{new}})$ асинхронно копируются в свои основные места на диске.

  flowchart LR
    subgraph Journal ["Кольцевой журнал на диске (Последовательная запись)"]
        TXB["1. TxB (TID=42)<br/>Дескриптор"] --> JB["2. Битмап B в журнале"]
        JB --> JI["3. Inode I в журнале"]
        JI --> JD["4. Данные D_new в журнале"]
        JD ==>|"★Аппаратный барьер FLUSH"| TXE["5. TxE (TID=42)<br/>Атомарный блок Commit"]
    end

    subgraph Home ["Основные места на диске (Home Locations)"]
        HB["Основная битовая карта"]
        HI["Основная таблица Inode"]
        HD["Основной блок данных"]
    end

    TXE ==>|"6. Checkpoint (Асинхронная запись)"| HB
    TXE ==>|"6. Checkpoint"| HI
    TXE ==>|"6. Checkpoint"| HD

Сбой ДО записи TxE: основные области диска не затронуты; при перезагрузке незавершённая запись в журнале просто отбрасывается.
Сбой ПОСЛЕ записи TxE: при перезагрузке система идемпотентно повторно копирует (Redo replay) блоки из журнала в основные места за несколько миллисекунд. Современная ext4 устраняет даже промежуточный барьер за счёт контрольных сумм журнала (CRC32C) внутри TxE.

Чтобы избежать двукратной записи всех данных ($2\times$ Write Amplification), режим по умолчанию data=ordered в ext4 журналирует только метаданные $(I, B)$, но требует, чтобы блок данных $D_{\text{new}}$ был полностью записан на своё основное место ДО того, как блок фиксации метаданных TxE попадёт в журнал. В реляционных СУБД протокол ARIES (Mohan et al., 1992) реализует политику Steal / No-Force с метками pageLSN и тремя фазами: Analysis, Redo (Repeating History) и Undo (с компенсационными записями CLR).

5. Поколение 3: Копирование при записи (Copy-on-Write, CoW) и деревья Меркла (ZFS / Btrfs)

Файловые системы нового поколения (ZFS, Btrfs, APFS) полностью запрещают перезапись блоков на месте (In-Place Overwrite) и используют Copy-on-Write (CoW / Теневая страничная организация):

Любой изменённый блок данных $D_{2,\text{new}}$ и его родительский inode $I_{v2}$ всегда записываются в новые свободные блоки, оставляя старые блоки $D_{2,\text{old}}$ нетронутыми.
Когда все новые дочерние блоки записаны на диск, одна атомарная запись переключает корневой блок (Uberblock в ZFS) с $U_1$ на $U_2$.
Преимущества: мгновенное восстановление за $0$ секунд без проигрывания журнала, мгновенные снимки (Snapshots) за $O(1)$ без копирования и автоматическое самовосстановление (Self-Healing) от тихого повреждения битов (Bit Rot) благодаря деревьям Меркла с 256-битными криптографическими контрольными суммами в каждом родительском указателе.

6. Ловушки `fsync()` для разработчиков и тестирование методом внесения неисправностей

Даже на журналируемой или CoW-файловой системе замена файла через rename("config.json.tmp", "config.json") без предварительного вызова fsync() приводит к появлению пустых файлов размером $0$ байт после сбоя питания при отложенном выделении (Delayed Allocation в ext4), так как переименование метаданных фиксируется раньше сброса страниц данных из кэша!

Полный 6-шаговый протокол безопасного атомарного сохранения файла: (1) write() во временный файл $\to$ (2) fsync(fd) временного файла $\to$ (3) close(fd) $\to$ (4) атомарный rename() $\to$ (5) открытие родительского каталога и fsync(dir_fd) для сохранения записи каталога $\to$ (6) close(dir_fd).

Как показал скандал fsyncgate в PostgreSQL в 2018 году (когда ядро Linux помечало грязную страницу в ОЗУ как Clean после ошибки ввода-вывода EIO во время fsync(), что было исправлено механизмом errseq_t), современная разработка систем хранения невозможна без фреймворков систематического внесения сбоев (Fault Injection), таких как ALICE и CrashMonkey, проверяющих все допустимые перестановки команд при внезапном отключении питания.