Использование `badblocks` на современных дисках.

Вопрос 1:

Что касается -b вариант: это зависит от вашего диска. Современные большие диски имеют блоки по 4 КБ, и в этом случае вам следует установить -b 4096, Вы можете получить размер блока из операционной системы, и он также обычно может быть получен либо путем считывания информации о диске с метки, либо путем поиска номера модели диска. Если -b установлен на что-то большее, чем размер вашего блока, целостность badblocks результаты могут быть скомпрометированы (то есть вы можете получить ложноотрицательные результаты: плохие блоки не найдены, когда они могут существовать). Если -b установлен на что-то меньшее, чем размер блока вашего диска, скорость badblocks Бег может быть скомпрометирован. Я не уверен, но могут быть другие проблемы с настройкой -b к чему-то меньшему, чем размер вашего блока, так как он не проверяет целостность всего блока, все равно возможно получить ложноотрицательные результаты, если он установлен слишком маленьким.

-c Опция соответствует тому, сколько блоков нужно проверить одновременно. Пакетное чтение / запись, в основном. Эта опция не влияет на целостность ваших результатов, но она влияет на скорость, с которой badblocks пробеги. badblocks (опционально) будет записывать, затем читать, буферизовать, проверять, повторять для каждого N блоков, как указано -c, Если -c установлен слишком низко, это сделает ваш badblocks Запуски выполняются намного дольше, чем обычно, поскольку постановка в очередь и обработка отдельного запроса ввода-вывода влечет за собой дополнительные расходы, и диск также может налагать дополнительные накладные расходы на каждый запрос. Если -c установлен слишком высоко, badblocks может не хватить памяти. Если это произойдет, badblocks потерпит неудачу довольно быстро после его запуска. Дополнительные соображения здесь включают параллель badblocks работает: если вы бежите badblocks против нескольких разделов на одном диске (плохая идея) или против нескольких дисков по одному каналу ввода-вывода, вы, вероятно, захотите настроить -c к чему-то разумно высокому, учитывая память, доступную для badblocks так что параллельные прогоны не борются за пропускную способность ввода-вывода и могут распараллеливать в здравом смысле.

Вопрос 2:

Вопреки тому, что указывают другие ответы, -wТест в режиме записи не более или менее надежен, чем неразрушающий тест чтения-записи, но в два раза быстрее, за счет того, что разрушает все ваши данные. Я объясню почему:

В неразрушающем режиме, badblocks делает следующее:

1. Прочитайте существующие данные, проверьте их (прочитайте еще раз при необходимости) и сохраните их в памяти.
2. Напишите предопределенный шаблон (переопределяемый с помощью -p вариант, хотя обычно не обязательно) в блок.
3. Прочитайте блок обратно, убедившись, что считанные данные совпадают с шаблоном.
4. Запишите исходные данные обратно на диск.
   • I'm not sure about this, but it also probably re-reads and verifies that the original data was written successfully and still checksums to the same thing.

In destructive (-w) mode, badblocks only does steps 2 and 3 above. This means that the number of read/write operations needed to verify data integrity is cut in half. If a block is bad, the data will be erroneous in either mode. Of course, if you care about the data that is stored on your drive, you should use non-destructive mode, as -w will obliterate all data and leave badblocks' patterns written to the disk instead.

Caveat: if a block is going bad, but isn't completely gone yet, some read/write verification pairs may work, and some may not. In this case, non-destructive mode may give you a more reliable indication of the "mushiness" of a block, since it does two sets of read/write verification (maybe--see the bullet under step 4). Even if non-destructive mode is more reliable in that way, it's only more reliable by coincidence. The correct way to check for blocks that aren't fully bad but can't sustain multiple read/write operations is to run badblocks multiple times over the same data, using the-p вариант.

Вопрос 3:

If SMART is reallocating sectors, you should probably consider replacing the drive ASAP. Drives that lose a few sectors don't always keep losing them, but the cause is usually a heavily-used drive getting magnetically mushy, or failing heads/motors resulting in inaccurate or failed reads/writes. The final decision is up to you, of course: based on the value of the data on the drive and the reliability you need from the systems you run on it, you might decide to keep it up. I have some drives with known bad blocks that have been spinning with SMART warnings for years in my fileserver, but they're backed up on a schedule such that I could handle a total failure without much pain.

1) Если ваш современный диск использует размер сектора, отличный от 512b - тогда вам нужно установить этот размер с помощью -b вариант (т.е. -b 4096). Без этой опции ваша проверка будет выполняться намного медленнее, поскольку каждый реальный сектор будет повторяться несколько раз (8 раз в случае сектора 4k). Также, как упомянул Оливье Дюлак в комментарии к вопросу - block is indeed 1 block, and not 1/2 or 1/4th or even 2 (or more) blocks.

вариант -c подразумевают, сколько секторов tryid одновременно. Это может повлиять на производительность, а значение этой производительности может зависеть от конкретной модели диска.

2) write-mode test - Насколько я понимаю, он будет только проверять, есть ли у вас грубая или программная ошибка (так называемая деградация данных, "гниение битов", разрушение носителей, сектора UNC)

3) Я бы не стал доверять SMART отчету в определенный момент времени. Более важно, как ценности изменяются во времени. Также здесь представлено исследование Google Failure Trends для большого количества накопителей на жестких дисках, и вот некоторые его обсуждения. Вот цитата из исследования:

Несмотря на эту высокую корреляцию, мы заключаем, что модели, основанные только на параметрах SMART, вряд ли будут полезны для прогнозирования отказов отдельных накопителей.

Что касается упоминания другим о замене диска - возможно, у вас проблема не с жестким диском, а с деградацией данных в режиме без вывода сообщений (гниение битов, разрушение носителей, сектора UNC). В этом случае нет смысла заменять диск, но вместо этого полезно выполнять чтение / запись одних и тех же данных обратно на диск. Вы можете посмотреть здесь, как это можно решить.

Если у вас возникла серьезная ошибка, вы можете попытаться переразбить диск так, чтобы плохая область находилась вне каких-либо разделов. Для меня такой подход был полезен, и такой плохой диск долгое время использовался без проблем.

Я бы оставил -b и -c по умолчанию, если у вас нет особых причин их менять. Возможно, вы могли бы установить -b на 4096, если ваш диск имеет размеры блока 4k.

Я бы посоветовал вам сначала запустить badblocks с неразрушающим тестом rw. Если он обнаружит поврежденные сектора, диск сломан и его необходимо заменить. Если он НЕ находит плохих блоков на неразрушающем, но вы все еще подозреваете, что он имеет плохие блоки, запустите деструктивный тест rw.

И, наконец, сколько перераспределений в SMART-секторе допустимо / следует ли немедленно заменить диски с ненулевым количеством перераспределений?

Я бы заменил диск, как только будут заменены сектора.

Это относится к разнице между режимом чтения плохих блоков (неразрушающим) и режимом записи (разрушающим):

Диск будет перераспределять поврежденный сектор только в случае сбоя записи. Ошибки чтения для файлов "исправляются" только при попытке перезаписать файл. Иначе. плохой блок остается частью файла в предположении, что вы можете что-то восстановить. Ошибки чтения для таблиц разделов можно "исправить", только запустив плохие блоки в режиме записи и воссоздав раздел.

Итак, режим чтения сообщит вам, где находятся плохие блоки, но ничего не сможет с ними поделать. Режим записи проверяет состояние каждого сектора и заставляет диск перераспределять поврежденный блок, но за счет уничтожения данных. Сделайте ваш выбор.

Чтобы ответить на ваш второй вопрос о переназначенных секторах, это зависит от обстоятельств. Я говорю из контекста домашнего пользователя, который (иногда) отслеживает подобные вещи.

• Насколько важны данные, хранящиеся на диске?
• Что будет потеряно, если привод вдруг перестанет работать?
• Есть ли резервные копии данных в другом месте?
• Является ли диск членом RAID, где потеря диска оказывает минимальное влияние?
• Растет ли количество переназначенных секторов?

Вот две ситуации, с которыми я столкнулся. У меня был RAID5 из 6 дисков по 200 ГБ. После сбоя питания, который привел к мерцанию индикаторов, один диск показал 14 переназначенных секторов и зарегистрировал несколько ошибок. Я осмотрел привод, больше никаких ошибок не регистрировалось, а количество переназначенных секторов оставалось стабильным. Я пришел к выводу, что привод пострадал из-за переходного режима питания и не вышел из строя. Я продолжал использовать его годами. Первоначальный RAID5 был снят с производства, но у меня есть два из этих дисков в эксплуатации, проработавшие около 10 лет. У них есть несколько переназначенных секторов. Я использую два из них с зеркалом для хранения инкрементных резервных копий из моей основной резервной копии. Таким образом, основная резервная копия видит (в основном) операции чтения, а записи идут на разные устройства. Если один из этих древних дисков выйдет из строя, другой должен продолжить работу. Если оба потерпят неудачу,Я заменяю их чем-нибудь другим и перезапускаю сценарий резервного копирования. Влияние отказа одного из этих дисков почти нулевое, поэтому я не беспокоюсь о переназначении секторов.

У меня был жесткий диск емкостью 2 ТБ, который был одним из пары зеркальных дисков, и на котором начали расти переназначенные секторы. Сначала были десятки, потом сотни, потом тысячи. Это длилось несколько лет. Другой диск в паре оставался исправным, и фактически медленно выходящий из строя вывод не был удален из массива. В конце концов я заменил оба диска на диски емкостью 6 ТБ, и увеличение количества переназначенных секторов перестало быть проблемой. У меня все еще есть диск, и он все еще "работает", даже с 4500 переназначенными секторами. Я поместил такие диски в тестовую систему (как член RAID), чтобы посмотреть, что происходит, когда кто-то действительно умирает. У меня было несколько возможностей поработать с этим, и при любых обстоятельствах замена прошла без драмы.

У меня действительно произошел сбой диска на моем основном резервном файловом сервере. Он не выдавал расширенного предупреждения, он просто перестал отвечать на команды SATA. Он был членом ZFS RAIDZ2, и я заменил его без каких-либо проблем. Фактически, на своем тестовом сервере я заменил вышедшие из строя диски без выключения и перезагрузки сервера.

Еще одно замечание: у меня есть резервные копии всех важных данных на месте и за его пределами. Если какая-то одна система потеряна, в другом месте будут две копии данных.