Является разрядная гниль на жестких дисках настоящей проблемой? Что может делаться с этим?
Прежде всего: Ваша файловая система не может иметь контрольных сумм, но Ваш жесткий диск сам имеет их. Существует S.M.A.R.T., например. Однажды один бит слишком многие были зеркально отражены, ошибка не может быть исправлена, конечно. И если Вы действительно неудачны, биты могут измениться таким способом, которым контрольная сумма не станет недопустимой; затем ошибка не будет даже обнаружена. Так, противные вещи могут произойти; но заявление, что случайные поразрядные операции немедленно повредят Вас данные, является поддельным.
Однако да, когда Вы помещаете триллионы битов на жесткий диск, они не останутся как этот навсегда; это - настоящая проблема! ZFS может сделать целостность, проверяющую каждый раз, когда данные считаны; это подобно тому, что Ваш жесткий диск уже делает самостоятельно, но это - другая гарантия, за которую Вы жертвуете некоторым пространством, таким образом, Вы увеличиваете устойчивость против повреждения данных.
То, когда Ваша файловая система достаточно хороша, вероятность ошибки, происходящей без того, чтобы быть обнаруженным, становится настолько низкой, что Вы не должны заботиться о том больше, и Вы могли бы решить, что, встраивая контрольные суммы в формат хранения данных используете, является ненужным.
Так или иначе: нет, не невозможно обнаружить.
Но файловая система, отдельно, никогда не может быть гарантией, что каждый отказ может быть восстановлен с; это не серебряная пуля. У Вас все еще должны быть резервные копии и план/алгоритм относительно того, что сделать, когда ошибка была обнаружена.
-
1Хорошо, согласно Википедии ( en.wikipedia.org/wiki/Error_detection_and_correction ) современные жесткие диски используют CRC' s, чтобы обнаружить ошибки и попытаться восстановить компакт-диск использования разрабатывают восстановление после ошибки. That' s достаточно хороший для меня. – scobi 24 October 2009 в 01:21
-
2Но если CRC хранится в том же месте (сектор) как данные этот won' t помогают для всех ошибочных случаев. Например, если существует голова, располагающая ошибочные данные, мог бы быть записан в неправильный сектор - но с корректной контрольной суммой = > Вы wouldn' t смочь обнаружить проблему. That' s, почему контрольные суммы в ZFS хранятся отдельно от данных, которые они защищают. – knweiss 4 December 2009 в 10:22
Да это - проблема, главным образом когда размеры диска повышаются. Большинство дисков SATA имеет URE (некорректируемая ошибка чтения) уровень 10^14. Или для каждых 12 ТБ чтения данных статистически поставщик диска говорит, что диск возвратит сбой чтения (обычно можно искать их на спецификациях диска). Диск продолжит работать просто великолепно для всех других частей диска. Диск Enterprise FC & SCSI обычно имеет уровень URE 10^15 (120 ТБ) наряду с небольшим количеством дисков SATA, который помогает уменьшить его.
Я никогда не видел к дисковой остановке вращаться в то же самое время, но у меня был raid5 объем, поразил эту проблему (5 лет назад с потребителем на 5400 об/мин диски PATA). Сбои диска, это отметило мертвый, и восстанавливание происходит с резервным диском. Проблема состоит в том, что во время восстанавливания второго диска не может считать что один небольшой блок данных. В зависимости от того, кто делает набег, весь объем мог бы быть мертвым или просто что мало блока может быть мертвым. Принятие, которое это только, что один блок мертв, при попытке считать его, Вы получите ошибку, но если Вы пишете в него диск, повторно отобразит его на другое местоположение.
Существует несколько методов для защиты от: raid6 (или эквивалентный), который защищает от двойного отказа диска, является лучшим, дополнительные являются осведомленной файловой системой URE, такой как ZFS, с помощью меньших групп набега так статистически у Вас есть более низкий шанс удара пределы диска URE (зеркальные большие диски или raid5 диски меньшего размера), дисковое вычищение и УМНЫЙ также помогает, но не является действительно защитой сам по себе, но используемый в дополнение к одному из вышеупомянутых методов.
Я справляюсь близко к 3 000 шпинделей в массивах, и массивы постоянно вычищают диски, ища скрытый URE's. И я получаю довольно постоянный поток их (каждый раз, когда он находит тот, который он фиксирует его перед сбоем диска и предупреждает меня), если я использовал raid5 вместо raid6, и один из дисков пошел абсолютно неисправный... Я был бы в беде, если бы это поразило определенные местоположения.
Жесткие диски обычно не кодируют биты данных единственными магнитными доменами - производители жестких дисков всегда знали, что магнитные домены могли зеркально отразить, и создавать в обнаружении ошибок и исправлении к дискам.
Если немного зеркальных отражений, диск содержит достаточно избыточных данных, что это может и исправляться в следующий раз, когда сектор читается. Вы видите это при проверке УМНОЙ статистики на диске как 'Корректируемый коэффициент ошибок'.
В зависимости от деталей диска это должно даже смочь восстановиться больше чем с одного зеркально отраженного бита в секторе. Будет предел числу зеркально отраженных битов, которые могут быть тихо исправлены, и вероятно другой предел числу зеркально отраженных битов, которые могут быть обнаружены как ошибка (даже если больше нет достаточного количества надежных данных для исправления его),
Это все составляет в целом то, что жесткие диски могут автоматически исправить большинство ошибок, как они происходят и могут надежно обнаружить большинство из остальных. Необходимо было бы быть, имеют большое количество битовых ошибок в единственном секторе, что все произошли, прежде чем тот сектор был считан снова, и ошибки должны будут быть таковы, что внутренние коды с обнаружением ошибок рассматривают его как допустимые данные снова, прежде чем у Вас когда-либо был бы тихий отказ. Это не невозможно, и я уверен, что компании, управляющие очень крупными информационными центрами, действительно видят, что он происходит (или скорее это происходит, и они не видят, что он происходит), но это - конечно, не столь большая проблема, как Вы могли бы думать.
Современные жесткие диски (начиная с 199x) не имеют только контрольных сумм, но также и ECC, который может обнаружить и исправить довольно немного "случайную" разрядную гниль. См.: http://en.wikipedia.org/wiki/S.M.A.R.T.
С другой стороны, определенные ошибки в микропрограммных и драйверах устройств могут также повредить данные в редком (иначе, QA поймал бы ошибки), случаи, которые будет трудно обнаружить, если у Вас не будет высокоуровневых контрольных сумм. Ранние драйверы устройств для SATA и NICs повредили данные и по Linux и по Солярису.
Контрольные суммы ZFS главным образом стремятся к ошибкам в более низком программном обеспечении уровня. Более новое устройство хранения данных/система баз данных как Гипертаблица также имеет контрольные суммы для каждого обновления для принятия мер против ошибок в файловых системах :)
Теоретически, это - повод для беспокойства. В сущности это - часть причины, что мы сохраняем дочерних/родителей/прародителей резервные копии. Ежегодные резервные копии должны быть сохранены в течение по крайней мере 5 лет, IMO, и если у Вас есть случай этого возвращения дальше, чем это, файл, очевидно, не настолько важен.
Если Вы не имеете дело с битами, которые могли потенциально превратить в жидкость чей-то мозг, я не уверен, что риск по сравнению с вознаграждением вполне на грани изменения файловых систем.
-
1Я don' t видят, как дочерние/родители/прародители резервные копии помогают. There' s никакой способ знать с той системой, если немного зеркально отражается, потому что пользователь намеревался изменить ее или если диск сделал это самостоятельно. Не без контрольной суммы некоторого вида. – scobi 23 October 2009 в 20:47
-
2Наличие нескольких резервных копий won' t помогают если Вы don' t знают, что данные в них хороши. Вы можете вручную контрольная сумма Ваши файлы, но ZFS делает настолько более автоматически и делает управление файловой системой легким. – Amok 23 October 2009 в 20:55
-
3Наличие резервных копий, которые возвращаются дальше, чем неделя/месяц, увеличивает Ваш шанс наличия хорошей копии файла. Я, вероятно, could' ve, более ясный об этом. – Kara Marfia 23 October 2009 в 22:14
-
4Проблема: как Вы знаете, что у Вас есть плохая копия? И как Вы знаете, какая копия, которая сохранена, является хорошей? Автоматизированным способом. – scobi 23 October 2009 в 22:34
-
5I' ve, замеченный, возможно, один файл, каждые несколько лет падают на повреждение, которое может быть результатом разрядной гнили, но я могу страдать от Синдрома Рыбки. Я мог понять разговор о резервных копиях, являющихся бесполезным, и I' ll удаляют если it' s наступление. Пришло время хорошо потраченное на чтение других ответов, независимо.;) – Kara Marfia 23 October 2009 в 23:00
Да это - проблема.
Это - одна из причин, почему RAID6 является теперь en модой (а также увеличивающиеся размеры HD увеличивают время для восстановления массива). Наличие двух блоков четности допускает дополнительное резервное копирование.
Системы RAID теперь также делают RAID, Вычищающий, который периодически читает дисковые блоки, проверки по сравнению с четностью, и заменяет его, если он находит, что блок плох.
-
1Будьте осторожной, целостностью данных, не функция всех систем RAID. – duffbeer703 24 October 2009 в 00:13
-
2С дисками терабайта существует столько битов, совместно использующих судьбу, и физическая область хранения немного является столь маленькой, что эта проблема становится более важной. В то же время вероятность отказа увеличивается так с дисками терабайта, что RAID6 недостаточно, если Вы не помещаете много дисков в пуле, говорите 8 или больше. С меньшими числами дисков лучше использовать дорожку зеркал иначе RAID 10. И RAID 6 (raidz2) и RAID 10 (шпулька создают c0t3d0 c0t4d0 зеркала c0t1d0 c0t2d0 зеркала mypool) возможны на ZFS. – Michael Dillon 24 October 2009 в 00:46
-
3RAID can' t говорят, какие данные хороши и который isn' t так это can' t фиксируют ошибки, это может просто обнаружить их. – Amok 30 October 2009 в 18:23
-
4Безудержно: Не как часть " RAID Standard" по сути, но усовершенствованные системы RAID (встроенные микропрограммные обеспечения, и т.д.) делают это – Matt Rogish 1 November 2009 в 01:29
Что касается заявления ОП о том, что RAID не понимает, какие данные хорошие, а какие плохие.
Контроллеры RAID используют как минимум (нечетные / четные) биты четности на каждой полосе данные. Это для всего; полосы данных на диске и полосы данных четности (резервной копии).
Это означает, что для любого типа RAID, который имеет чередование для избыточности (RAID 5/6), контроллер может точно определить, изменилась ли исходная полоса данных, а также, если полоса данных избыточности изменилась.
Если вы вводите вторую избыточную полосу, такую как RAID6, у вас должно быть 3 полосы данных, на трех разных дисках будут повреждены, и все они будут соответствовать одним и тем же фактическим данным файла. Помните, что большинство систем RAID используют относительно небольшие полосы данных (128 КБ или меньше).так что шансы "битовой гнили" выровнять до тех же 128 КБ того же файла практически невозможны.
Да, это реальная проблема, но вопрос в том, стоит ли вам об этом беспокоиться или нет.
Если у вас есть только жесткий диск, полный изображений, это может не стоить усилий. Он полон важных научных данных, это может быть другая история, вы поняли.
Да, битрот - это проблема.
Я написал инструмент под названием chkbit , чтобы помочь обнаружить битрот:
Любое облачное или локальное хранилище может быть подвержено повреждению данных и/или битрейту. Хотя некоторые файловые системы имеют встроенную защиту, эта защита ограничивается носителем информации.
chkbit создаст хэш, который следует за вашими данными с локального носителя в облако или резервную копию. Это позволяет вам проверять целостность ваших данных, куда бы они ни перемещались.
- запустите chkbit в своей системе
- переместите данные в новую систему (резервное копирование/восстановление)
- убедитесь, что с chkbit все в порядке