Я задаю этот вопрос от имени другого пользователя, который поднял эту проблему в чате Ubuntu.
Гарантируют ли журнальные файловые системы, что в случае сбоя питания не произойдет повреждения?
Если этот ответ зависит от файловой системы, укажите, какие из них защищают от повреждения, а какие - нет.
Ответы:
Там нет никаких гарантий. Журналируемая файловая система более устойчива и менее подвержена коррупции, но не защищена.
Весь журнал - это список операций, которые недавно были выполнены с файловой системой. Важнейшей частью является то, что запись в журнале делается до того, как будут выполнены операции. Большинство операций имеют несколько этапов. Например, удаление файла может повлечь за собой удаление записи файла в оглавлении файловой системы, а затем пометить сектора на диске как свободные. Если что-то происходит между этими двумя шагами, журнализированная файловая система может немедленно сообщить об этом и выполнить необходимую очистку, чтобы все было согласованно. Это не относится к файловой системе без журналирования, которая должна искать все содержимое тома, чтобы найти ошибки.
Хотя это ведение журнала гораздо менее подвержено коррупции, чем не ведение журнала, коррупция все же может иметь место. Например, если жесткий диск работает со сбоями или если запись в сам журнал прерывается или прерывается.
Основная предпосылка ведения журнала состоит в том, что написание записи в журнале обычно происходит гораздо быстрее, чем фактическая транзакция, которую она описывает. Таким образом, период между ОС, упорядочивающей запись (журнал), и жестким диском, выполняющим ее, намного короче, чем для обычной записи: более узкое окно для ошибок, но окно все еще есть.
Нет.
Наиболее распространенный тип ведения журнала, называемый ведением журнала метаданных, защищает только целостность файловой системы, а не данных. Это включает в себя xfsи ext3/ ext4в data=orderedрежиме по умолчанию .
Если не журналируемая файловая система испытывает сбой, она будет проверена при fsckследующей загрузке. fsckсканирует каждый индекс в файловой системе, ищет блоки, помеченные как использованные, но недоступные (т. е. не имеющие имени файла), и помечает эти блоки как неиспользуемые. Это занимает много времени.
В файловой системе ведения журнала метаданных вместо того, чтобы делать fsck, она знает, какие блоки находились в процессе изменения, поэтому она может пометить их как свободные, не выполняя поиск по всему разделу.
Существует менее распространенный тип журналирования, называемый журналированием данных, что и ext3происходит, если вы подключаете его с data=journalопцией.
Он пытается защитить все ваши данные, записывая не только список логических операций, но и все содержимое каждой записи в журнал. Но поскольку он записывает ваши данные дважды, это может быть намного медленнее.
Как указывали другие, даже это не является гарантией, поскольку жесткий диск мог сообщить операционной системе, что он сохранил данные, хотя на самом деле он все еще находился в кеше жесткого диска.
Для получения дополнительной информации ознакомьтесь со статьей Wikipedia Journaling File System и разделом Data Mode документации ext4 .
data=journalимеет смысла?
Файловая система не может гарантировать согласованность своей файловой системы в случае сбоя питания, потому что она не знает, что будет делать оборудование.
Если жесткий диск буферизует данные для записи, но сообщает ОС, что они записали данные, и не поддерживает соответствующие барьеры записи, то может произойти неправильная запись, когда более ранняя запись не попала на диск, но более поздняя запись есть. См. Этот ответ о сбое сервера для более подробной информации.
Также положение головки на магнитном жестком диске контролируется электромагнитами. Если во время записи происходит сбой питания, некоторые данные могут продолжать записываться во время движения головок, повреждая данные в блоках, которые файловая система никогда не собиралась записывать.
ZFS, которая является закрытой, но не совсем журналируемой файловой системой, гарантированно защищает от повреждения после сбоя питания.
Не имеет значения, если текущая запись будет прервана посередине, так как в этом случае ее контрольная сумма будет, безусловно, неправильной, поэтому блок будет игнорироваться. Поскольку файловая система копируется при записи, предыдущие правильные данные (или метаданные) все еще находятся на диске и будут использоваться вместо них.
Ответ в большинстве случаев нет: