О журнале ZFS
2016-06-17 02:17 pm![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
waqurПоразительно, как много людей не понимают, почему полное отключение журналирования (ZIL) на ZFS — это абсолютно безопасно с точки зрения целостности данных. Лично я всегда начинаю настройку ZFS с того, что отключаю ZIL.
В отличие от NTFS/ext4/HFS+/UFS2, ZFS — это copy-on-write файловая система, всегда консистентная на диске. Все изменения пишутся в свободные блоки, метаданные организованы в дерево, а при закрытии транзакционной группы обновляется корневой указатель (на самом деле, там кольцевой буфер корневых указателей для wear leveling и не только). Из формулы "всегда консистентна на диске" в частности выводится "fsck для ZFS не нужен" и "воспроизведение журнала в загрузчике ОС не нужно".
В первой версии ZFS вообще не было журнала. fsync(2) и sync(2) просто были NOPами, как им и надлежит быть в дивном новом мире COW файловых систем. Но тут понабежали формалисты-теоретики от баз данных и принялись жаловаться, что формула fsync=NOP нарушает то, что скрывается за буковкой D в аббревиатуре ACID. Т.е. если сервер СУБД вслед за успешно выполненным SQL-запросом INSERT/UPDATE/DELETE словит незапланированную перезагрузку, то после возврата в строй его состояние будет не актуальным, а отстающим от актуального на 1-30 секунд. Повторюсь: файловая система будет целая, база данных будет целая, все связи не нарушены, только произойдёт как бы прыжок в прошлое, для всего набора данных, довольно короткий.
И вот в угоду этим нытикам был добавлен уродливый ZIL, позволяющий сократить расстояние между "контрольными точками" от 30 секунд до субсекундных значений, ценой двойной записи всех изменений на диск (как в файловых системах предыдущего поколения). Как по мне — можно было сделать так, чтобы системные вызовы fsync(2)/sync(2) просто блокировались на тех же 1-30 секунд до закрытия транзакционной группы в ZFS-пуле, чтобы теоретики, вещающие про POSIX-совместимость fsync(2), заткнулись уже. Далее те, кому жизненно важна буква D в ACID (это где-то в области финансовых транзакций), создают себе отдельный пул на SSD, где настраивают закрытие транзакционной группы (ZFS TXG) не раз в 30 секунд как по умолчанию, а раз в 1 секунду или чаще. Чтобы их SQL-запросики не застревали. IOPS-характеристики типичного энтерпрайзного SSD это позволяют.
В отличие от NTFS/ext4/HFS+/UFS2, ZFS — это copy-on-write файловая система, всегда консистентная на диске. Все изменения пишутся в свободные блоки, метаданные организованы в дерево, а при закрытии транзакционной группы обновляется корневой указатель (на самом деле, там кольцевой буфер корневых указателей для wear leveling и не только). Из формулы "всегда консистентна на диске" в частности выводится "fsck для ZFS не нужен" и "воспроизведение журнала в загрузчике ОС не нужно".
В первой версии ZFS вообще не было журнала. fsync(2) и sync(2) просто были NOPами, как им и надлежит быть в дивном новом мире COW файловых систем. Но тут понабежали формалисты-теоретики от баз данных и принялись жаловаться, что формула fsync=NOP нарушает то, что скрывается за буковкой D в аббревиатуре ACID. Т.е. если сервер СУБД вслед за успешно выполненным SQL-запросом INSERT/UPDATE/DELETE словит незапланированную перезагрузку, то после возврата в строй его состояние будет не актуальным, а отстающим от актуального на 1-30 секунд. Повторюсь: файловая система будет целая, база данных будет целая, все связи не нарушены, только произойдёт как бы прыжок в прошлое, для всего набора данных, довольно короткий.
И вот в угоду этим нытикам был добавлен уродливый ZIL, позволяющий сократить расстояние между "контрольными точками" от 30 секунд до субсекундных значений, ценой двойной записи всех изменений на диск (как в файловых системах предыдущего поколения). Как по мне — можно было сделать так, чтобы системные вызовы fsync(2)/sync(2) просто блокировались на тех же 1-30 секунд до закрытия транзакционной группы в ZFS-пуле, чтобы теоретики, вещающие про POSIX-совместимость fsync(2), заткнулись уже. Далее те, кому жизненно важна буква D в ACID (это где-то в области финансовых транзакций), создают себе отдельный пул на SSD, где настраивают закрытие транзакционной группы (ZFS TXG) не раз в 30 секунд как по умолчанию, а раз в 1 секунду или чаще. Чтобы их SQL-запросики не застревали. IOPS-характеристики типичного энтерпрайзного SSD это позволяют.
