Fast Commits в fsync
Я с универских времен изучал fsync, но только на уровне, что этот вызов -- самая последняя инстанция перед тем, как сказать диску, что надо всё на него сбросить. К своему удивлению, спустя несколько лет, я наткнулся на работу коллеги про Fast Commits, которая пытается соптимизировать fsync в EXT4 в Linux уже несколько лет, и, кажется, у этого дела виднеется свет в конце тунеля. Также получили на USENIX ATC 2024 best paper award https://www.usenix.org/conference/atc24/presentation/shirwadkar
fsync в EXT4 работает через алгоритм JBD2 (Journaling Block Device v2), который хранит последние операции работы с диском и применяет их, гарантируя, что всё корректно применится даже в случае отказа машинки. Первый инсайт, который я узнал -- всё это дело происходит раз в 5 секунд и при каждом вызове fsync.
Второй инсайт, что JBD2 хранит минимум 3 блока по 4kb на каждую операцию: блок дескриптора (метаданные о других блоках в коммите), по крайней мере один измененный блок метаданных и блок маркера коммита, указывающий конец коммита. Метаданные о дополнительных блоках нужны в интересных случаях, когда, например, машинка умерла, при загрузке она начнёт восстаналивать данные и потом она во время этого умирает. Идемпотентность можно только гарантировать с помощью сравнения изменений, поэтому JBD2 имеет чуть бОльший оверхед, чем возможно представляют себе люди. Из-за маркера коммита получается, что JBD2 делает минимум 2 операции с диском, что тоже немного неожиданно.
Третий инсайт, что fsync будит свой поток и из-за этого происходит 2 переключения контекста, что тоже стало неожиданностью для меня.
Fast commits представляют возможность избежать минусов упомянутых выше. Например, для идемпотентных операций, которые легче проверяются, например, переименование файла или добавление блоков к файлу можно писать достаточно маленькие куски с метаданными в журнал. В итоге и поток переключать не надо, и одна операция с диском и идемпотентность сохраняется.
Как можно догадаться, даже такая простая идея заняла около 6 лет, чтобы протащить в ядро. Очень много уделялось времени обратной совместимости, а также что делать со сложными операциями, например, filesystem resize, которые обязаны уйти в старый JBD2 и как теперь работать с обоими журналами.
В целом на бенчмарках экономия в 100-200 микросекунд, что для частых fsync собирается в неплохую историю. Для HDD это не такие большие цифры, а вот с развитием SSD это уже значительно. Включить на linux это дело можно через tune2fs -O fast_commit.
Я с универских времен изучал fsync, но только на уровне, что этот вызов -- самая последняя инстанция перед тем, как сказать диску, что надо всё на него сбросить. К своему удивлению, спустя несколько лет, я наткнулся на работу коллеги про Fast Commits, которая пытается соптимизировать fsync в EXT4 в Linux уже несколько лет, и, кажется, у этого дела виднеется свет в конце тунеля. Также получили на USENIX ATC 2024 best paper award https://www.usenix.org/conference/atc24/presentation/shirwadkar
fsync в EXT4 работает через алгоритм JBD2 (Journaling Block Device v2), который хранит последние операции работы с диском и применяет их, гарантируя, что всё корректно применится даже в случае отказа машинки. Первый инсайт, который я узнал -- всё это дело происходит раз в 5 секунд и при каждом вызове fsync.
Второй инсайт, что JBD2 хранит минимум 3 блока по 4kb на каждую операцию: блок дескриптора (метаданные о других блоках в коммите), по крайней мере один измененный блок метаданных и блок маркера коммита, указывающий конец коммита. Метаданные о дополнительных блоках нужны в интересных случаях, когда, например, машинка умерла, при загрузке она начнёт восстаналивать данные и потом она во время этого умирает. Идемпотентность можно только гарантировать с помощью сравнения изменений, поэтому JBD2 имеет чуть бОльший оверхед, чем возможно представляют себе люди. Из-за маркера коммита получается, что JBD2 делает минимум 2 операции с диском, что тоже немного неожиданно.
Третий инсайт, что fsync будит свой поток и из-за этого происходит 2 переключения контекста, что тоже стало неожиданностью для меня.
Fast commits представляют возможность избежать минусов упомянутых выше. Например, для идемпотентных операций, которые легче проверяются, например, переименование файла или добавление блоков к файлу можно писать достаточно маленькие куски с метаданными в журнал. В итоге и поток переключать не надо, и одна операция с диском и идемпотентность сохраняется.
Как можно догадаться, даже такая простая идея заняла около 6 лет, чтобы протащить в ядро. Очень много уделялось времени обратной совместимости, а также что делать со сложными операциями, например, filesystem resize, которые обязаны уйти в старый JBD2 и как теперь работать с обоими журналами.
В целом на бенчмарках экономия в 100-200 микросекунд, что для частых fsync собирается в неплохую историю. Для HDD это не такие большие цифры, а вот с развитием SSD это уже значительно. Включить на linux это дело можно через tune2fs -O fast_commit.