Журналирующие файловые системы гарантируют против повреждения после сбоя питания?
Мои favs ниже. Я использую большинство из них регулярно
df-k (проверяют файловые системы) уничтожают или уничтожают-9 (уничтожьте процесс), установите-o vi (установите свою командную строку на vi), Топас (инструмент производительности) монтирует/размонтирует
о, да и как я мог забыть> (для перенаправления вывода в файл) ls> /tmp/tmp.txt
Намного больше, но некоторые от вершины меня направляются.
Нет никаких гарантий. Файловая система Журналирования более эластична и менее подвержена повреждению, но не неуязвима.
Весь журнал, список операций, которые были недавно сделаны к файловой системе. Ключевая роль - то, что запись журнала сделана, прежде чем операции происходят. Большинство операций имеет несколько шагов. При удалении файла, например, мог бы повлечь за собой удаление записи файла в оглавлении файловой системы и затем маркировки секторов на диске как свободное. Если что-то происходит между двумя шагами, журналируемая файловая система может сразу сказать и выполнить необходимую уборку для хранения всего последовательным. Дело обстоит не так с нежурналируемой файловой системой, которая должна посмотреть на все содержание объема для нахождения ошибок.
В то время как это журналирование намного менее подвержено повреждению, чем не журналирование, повреждение может все еще произойти. Например, если жесткий диск механически неправильно функционирует или если записи к самому журналу перестали работать или прерванные.
Основная предпосылка журналирования - то, что запись записи журнала намного более быстра, обычно, чем фактическая транзакция, которую это описывает, будет. Так, период между ОС, заказывая (журнал) запись и жестким диском, выполняющим его, намного короче, чем для нормальной записи: более узкое окно для вещей пойти не так, как надо в, но существует все еще окно.
-
1Вы могли уточнить немного то, почему это верно? Возможно, Вы могли дать пример того, как повреждение произойдет в определенном сценарии. Edison See – Nathan Osman 06.05.2011, 05:57
-
2@George мой расширенный ответ. – Andrew Lambert 06.05.2011, 06:21
-
3Тот последний бит является неправильным; нет никакого окна для вещей пойти не так, как надо. Так как это записывает то, что это собирается сделать, прежде чем это начнет делать его, операция может быть перезапущена после сбоя питания, неважно, в том, какая точка это происходит во время операции. Это - вопрос упорядочивания, не синхронизации. – psusi 06.05.2011, 20:58
-
4@psusi там является все еще окном для записи к журналу, который будет прерван. Записи журнала могут казаться атомарными к ОС, но они - все еще записи к диску. – Andrew Lambert 07.05.2011, 00:23
-
5@Amazed они являются атомарными, потому что у них есть порядковые номера и/или контрольные суммы, таким образом, запись журнала или записана полностью, или нет. Если это не записано полностью, это просто проигнорировано после системных перезапусков, и никакие дальнейшие изменения не были внесены в фс, таким образом, это остается последовательным. – psusi 07.05.2011, 04:57
Нет.
Наиболее распространенный тип журналирования, названного журналированием метаданных, только защищает целостность файловой системы, не данных. Это включает xfs, и ext3/ext4 в значении по умолчанию data=ordered режим.
Если файловая система нежурналирования перенесет катастрофический отказ, то она будет проверена с помощью fsck на следующей начальной загрузке. fsck сканирует каждый inode в файловой системе, ища блоки, которые отмечены, как используется, но не достижимы (т.е. не имейте никакого имени файла), и отмечает те блоки как неиспользованные. Выполнение этого занимает много времени.
С метаданными, журналирующими файловую систему, вместо того, чтобы делать fsck, это знает, какими блоками это было посреди изменения, таким образом, это может отметить их как свободных, не ища целый раздел их.
Существует менее общий тип журналирования, названного журналированием данных, которое является что ext3 делает, если Вы монтируете его с data=journal опция.
Это пытается защитить все Ваши данные путем написания не только списка логических операций, но также и всего содержания каждой записи к журналу. Но потому что это пишет Ваши данные дважды, это может быть намного медленнее.
Как другие указали, даже это не гарантия, потому что жесткий диск, возможно, сказал операционной системе, что это хранило данные, когда это факт это было все еще в кэше жесткого диска.
Для получения дополнительной информации смотрите на статью Wikipedia Journaling File System и раздел Data Mode ext4 документации.
-
1+1 для различия между повреждением файловой системы и повреждением данных. То небольшое различие является вполне doozy на практике. – SplinterReality 06.05.2011, 11:03
-
2Извините мое чрезвычайное незнание, но не делает
data=journalкак функция не имеют никакого смысла вообще? – boehj 06.05.2011, 13:57 -
3Снова, ОС знает, когда данные кэшей диска и вынуждают ее сбросить ее при необходимости для поддержания когерентной фс. Ваш файл данных, конечно, может быть потерян или поврежден, если приложение, которое писало это, когда отказавшее питание не делало так тщательно, и это применяется, используете ли Вы data=journal. – psusi 06.05.2011, 21:11
-
4@psusi не имеет значения, насколько осторожный программа является в письменной форме данными, много жестких дисков тихо повреждает данные по ЧТЕНИЮ stackoverflow.com/q/34141117/3338098 – user3338098 01.08.2016, 19:30
-
5@psusi, кажется, что путь вещи, как предполагается, редко является способом, которым на самом деле вещи. en.wikipedia.org/wiki/Data_corruption#SILENT
As another example, a real-life study performed by NetApp on more than 1.5 million HDDs over 41 months found more than 400,000 silent data corruptions, out of which more than 30,000 were not detected by the hardware RAID controller. Another study, performed by CERN over six months and involving about 97 petabytes of data, found that about 128 megabytes of data became permanently corrupted.– user3338098 07.03.2017, 22:06
Файловая система не может гарантировать непротиворечивость своей файловой системы, если сбой питания произойдет, потому что это не знает то, что сделают аппаратные средства.
Если жесткий диск буферизует данные для записи, но говорит ОС, что это записало данные и не поддерживает соответствующие барьеры записи, то неисправные записи могут произойти, где более ранняя запись не поразила диск, но более поздний имеет. Дополнительную информацию см. в этом ответе serverfault.
Кроме того, положением головы на магнитном жестком диске управляют с электромагнитами. Если сбои питания посреди записи, для некоторых данных возможно продолжить писаться, в то время как головы перемещаются, повреждая данные по блокам, что файловая система никогда не намеревалась быть записанной.
-
1Разве встроенное микропрограммное обеспечение диска не достаточно умно для приостановки записи при отречении от головы? – Nathan Osman 06.05.2011, 09:43
-
2@George: это собирается зависеть от диска. Существует много там, и Вы не знаете, как хорошо Ваш (дешевый) диск делает вещи. – camh 06.05.2011, 10:54
-
3Жесткий диск говорит ОС, если это использует запись позади кэша, и ОС принимает меры, чтобы гарантировать, что они сбрасываются в правильном порядке. Также диски разработаны так, чтобы, когда сбои питания, они прекращают писать. Я видел некоторые случаи, где сектор, записанный во время потерь мощности, становится поврежденным, потому что это не закончило обновлять ECC (но может быть легко переписан правильно), но никогда не слышал о случайных секторах, повреждаемых на потерях мощности. – psusi 06.05.2011, 21:05
ZFS, который близок, но не точно файловая система журналирования, гарантирует дизайном против повреждения после сбоя питания.
Не имеет значения, если продолжающаяся запись будет прервана в середине как в таком случае, то его контрольная сумма будет, конечно, неправильной, таким образом, блок будет проигнорирован. Поскольку файловая система является копией на записи, предыдущие корректные данные (или метаданные) находятся все еще на диске и будут использоваться вместо этого.
Ответ в большинстве случаев нет:
- Как уже mikel сказал, большинство файловых систем журналирования может только защитить метаданные файла (информация как название файла, его размера, его полномочий, и т.д.), не данные файла (содержание файла). Это происходит, потому что защита данных файла приводит к очень медленному (на практике бесполезный) файловая система.
- Так как журнал является также специальным видом файла, хранившего на жестком диске, он может быть поврежден после сбоя питания. Таким образом, если журнал повреждается, файловая система не может завершить незавершенные транзакции, которые происходили, когда сбой питания произошел.
-
1Что события могли привести к поврежденному журналу? Единственной вещью, о которой я мог думать, были поврежденные секторы - там что-либо еще? – Nathan Osman 06.05.2011, 19:35
-
2