Журнал на ZFS
2011-11-29 10:04 am![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
waqurПодобно другим современным файловым системам, ZFS содержит журнал — ZFS Intent Log (ZIL).
Однако поскольку ZFS — это файловая система, построенная по технологии Copy-on-Write, её журнал имеет отличия от журнала традиционной файловой системы, такой как ext3 или NTFS. Какие?
(1) ZFS может всегда безопасно потерять журнал
Поскольку состояние файловой системы на диске (без журнала) всегда целостно и запись изменённых блоков происходит только в свободное место на диске, файловая система — метаданные и данные пользователя — не повредится даже если журнал был утрачен или разрушен. Поэтому для ZFS даже не существует утилиты fsck — она не нужна. ext3fs при потере журнала частично повредится, и потребует применения fsck. Будут повреждены как пользовательские данные, так и метаданные ФС, возможен вариант, когда вся ФС будет потеряна. В любом случае fsck не сможет "отремонтировать" пользовательские данные, только метаданные и иногда с потерями.
(2) ZFS может перенести журнал на SSD
Как следствие первого пункта: это позволит заметно ускорить дисковую подсистему, т.к. исключается двойная запись изменений на HDD, а на SSD запись идёт намного быстрее (write IOPS** примерно в 100 раз выше, чем для HDD). В случае выхода из строя SSD* (с одновременной незапланированной перезагрузкой), файловая система ZFS на HDD просто вернётся в прошлое, более отдалённое прошлое, чем с журналом, только и всего. В случае с ext3 вы тоже можете перенести журнал на SSD, но тут полная аналогия с грибами, которые можно есть все, но некоторые из них только один раз.
Также ZFS может умножить на 100 read IOPS** жёсткого диска за счёт L2ARC — кэширования чтения на SSD. Опять же, потеря кэша чтения не влечёт потерю данных.
* MTBF для SSD под нагрузкой — примерно 12 месяцев. Они живут красиво, но недолго. Кстати, именно поэтому HHD — гиблая идея. Ну и ещё потому, что функция плотности вероятности чтения данных с диска индивидуальна для разных заказчиков. Там во всех случаях распределение Парето, однако его коэффициент и соответствующее соотношение ёмкости HDD и SSD — зависит от приложения.
** IOPS для жёсткого диска ограничен скоростью вращения дискового пакета (75-100 для 7200rpm, 125-150 для 10000rpm, 175-210 для 15000rpm).
(3) В ZFS журнал может быть проигнорирован в контексте загрузчика ОС
Загрузчик "монтирует" файловую систему в режиме "только для чтения". ZFS без журнала — это та же ZFS, только в более отдалённом прошлом. Поскольку ядро ОС, файлы драйверов, конфиги лоадера и всё такое прочее не меняются слишком часто — загрузчик ZFS может просто читать ФС и игнорировать журнал.
Для загрузчика NTFS, файловая система без журнала — это просто кровавое месиво, где нет ни каталогов ни файлов, покуда весь журнал не будет прочитан и повторно проигран. Загрузчик вынужден делать запись в ФС во время своей работы, что не очень хорошо; и загрузка невозможна, если журнал как-то повреждён. Кроме того, возникает проблема курицы и яйца: сам загрузчик должен храниться вне журналируемой области и обновляться по принципу Copy-on-Write (не реализовано в NTFS). В UFS загрузчик обычно хранится в отдельном разделе, в нормальных линуксах — тоже (/boot это отдельная ФС ext2).
Однако поскольку ZFS — это файловая система, построенная по технологии Copy-on-Write, её журнал имеет отличия от журнала традиционной файловой системы, такой как ext3 или NTFS. Какие?
(1) ZFS может всегда безопасно потерять журнал
Поскольку состояние файловой системы на диске (без журнала) всегда целостно и запись изменённых блоков происходит только в свободное место на диске, файловая система — метаданные и данные пользователя — не повредится даже если журнал был утрачен или разрушен. Поэтому для ZFS даже не существует утилиты fsck — она не нужна. ext3fs при потере журнала частично повредится, и потребует применения fsck. Будут повреждены как пользовательские данные, так и метаданные ФС, возможен вариант, когда вся ФС будет потеряна. В любом случае fsck не сможет "отремонтировать" пользовательские данные, только метаданные и иногда с потерями.
(2) ZFS может перенести журнал на SSD
Как следствие первого пункта: это позволит заметно ускорить дисковую подсистему, т.к. исключается двойная запись изменений на HDD, а на SSD запись идёт намного быстрее (write IOPS** примерно в 100 раз выше, чем для HDD). В случае выхода из строя SSD* (с одновременной незапланированной перезагрузкой), файловая система ZFS на HDD просто вернётся в прошлое, более отдалённое прошлое, чем с журналом, только и всего. В случае с ext3 вы тоже можете перенести журнал на SSD, но тут полная аналогия с грибами, которые можно есть все, но некоторые из них только один раз.
Также ZFS может умножить на 100 read IOPS** жёсткого диска за счёт L2ARC — кэширования чтения на SSD. Опять же, потеря кэша чтения не влечёт потерю данных.
* MTBF для SSD под нагрузкой — примерно 12 месяцев. Они живут красиво, но недолго. Кстати, именно поэтому HHD — гиблая идея. Ну и ещё потому, что функция плотности вероятности чтения данных с диска индивидуальна для разных заказчиков. Там во всех случаях распределение Парето, однако его коэффициент и соответствующее соотношение ёмкости HDD и SSD — зависит от приложения.
** IOPS для жёсткого диска ограничен скоростью вращения дискового пакета (75-100 для 7200rpm, 125-150 для 10000rpm, 175-210 для 15000rpm).
(3) В ZFS журнал может быть проигнорирован в контексте загрузчика ОС
Загрузчик "монтирует" файловую систему в режиме "только для чтения". ZFS без журнала — это та же ZFS, только в более отдалённом прошлом. Поскольку ядро ОС, файлы драйверов, конфиги лоадера и всё такое прочее не меняются слишком часто — загрузчик ZFS может просто читать ФС и игнорировать журнал.
Для загрузчика NTFS, файловая система без журнала — это просто кровавое месиво, где нет ни каталогов ни файлов, покуда весь журнал не будет прочитан и повторно проигран. Загрузчик вынужден делать запись в ФС во время своей работы, что не очень хорошо; и загрузка невозможна, если журнал как-то повреждён. Кроме того, возникает проблема курицы и яйца: сам загрузчик должен храниться вне журналируемой области и обновляться по принципу Copy-on-Write (не реализовано в NTFS). В UFS загрузчик обычно хранится в отдельном разделе, в нормальных линуксах — тоже (/boot это отдельная ФС ext2).
