Використання "поганих блоків" на сучасних дисках

Я хочу використати неполадки для перевірки своїх жорстких дисків і буду вдячний за уточнення його роботи.

Може хтось, будь ласка, пояснить найкращі варіанти для використання -bта -c? Я включив їхні визначення зі сторінки man, але не впевнений, чи будуть більші розміри корисними для сучасних дисків з 64 МБ оперативної пам’яті та 4 к секторами.

-b block-size       Specify the size of blocks in bytes. The default is 1024. 
-c number of blocks the number of blocks which are tested at a time. The default is 64

По-друге, я хотів би знати, чи тест режиму запису є більш ретельним, ніж неруйнівний режим читання-запису?

Нарешті, скільки перерозподілів секторів SMART є прийнятними / повинні бути негайно замінені диски з ненульовими підрахунками перерозподілу?

Питання 1:

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

В -cопції відповідає тому , скільки блоків повинні бути перевірені відразу. Базове читання / запис, в основному. Цей параметр не впливає на цілісність ваших результатів, але впливає на швидкість, з якою badblocksпрацює. badblocksбуде (необов'язково) писати, потім читати, буфер, перевіряти, повторювати для всіх N блоків, як зазначено в -c. Якщо -cвстановлено занадто низько, це призведе до того, що ваші badblocksзапуски займуть набагато більше часу, ніж звичайні, оскільки чергування та обробка окремого запиту вводу-виводу вимагає накладних витрат, а диск також може накладати додаткові накладні витрати на запит. Якщо -cвстановлено занадто високо, badblocksможливо , не вистачить пам'яті. Якщо це станеться, badblocksвийде з ладу досить швидко після її запуску. Додаткові міркування тут включають паралельні badblocksзапуски: якщо ви працюєтеbadblocksпроти декількох розділів на одному диску (погана ідея) або проти декількох дисків на одному каналі вводу-виводу, напевно, ви захочете налаштуватися -cна щось чудово високе, враховуючи наявну пам'ять, щоб badblocksпаралельні запуски не боролися за пропускну здатність IO і може паралелізуватися розумним чином.

Питання 2:

Попри те , що інші відповіді показують, тест записи режим не є більш-менш надійні , ніж тест неруйнівного читання-запису, але в два рази швидше, за рахунок того , щоб бути руйнівною для всіх ваших даних. Я поясню, чому:-w

У неруйнівному режимі badblocksвиконує наступні дії:

1. Прочитайте наявні дані, перевірте їх (за потреби прочитайте ще раз) та збережіть у пам'яті.
2. Напишіть заздалегідь заданий шаблон (замінюючи -pпараметр, хоча зазвичай це не потрібно) до блоку.
3. Прочитайте блок назад, переконавшись, що прочитані дані збігаються з шаблоном.
4. Запишіть оригінальні дані на диск.
   • Я не впевнений у цьому, але він також, ймовірно, перечитує та підтверджує, що вихідні дані були записані успішно та все ще контрольні суми до того ж.

У руйнівному ( -w) режимі виконуються badblocksлише кроки 2 та 3 вище. Це означає, що кількість операцій читання / запису, необхідних для перевірки цілісності даних, скорочується вдвічі. Якщо блок поганий, дані будуть помилковими в будь-якому режимі. Звичайно, якщо ви дбаєте про дані, що зберігаються на вашому диску, вам слід скористатися неруйнівним режимом, оскільки -wце знищить усі дані та залишить badblocksна диску диск «Шаблони».

Caveat: якщо блок йде погано, але ще не повністю вийшов, деякі пари перевірки читання / запису можуть працювати, а деякі - ні. У такому випадку неруйнівний режим може дати тобі більш надійну вказівку на «каламутність» блоку, оскільки він робить два набори перевірки читання / запису (можливо - див. Кулю в кроці 4). Навіть якщо неруйнівний режим таким чином надійніший, він лише надійніший за збігом обставин . Правильний спосіб перевірити наявність блоків, які не є повністю поганими, але не можуть витримати декілька операцій читання / запису, - це badblocksкілька разів виконувати одні і ті ж дані, використовуючи цю -pопцію.

Питання 3:

Якщо SMART перерозподіляє сектори, вам, ймовірно, слід подумати про заміну накопичувача якнайшвидше. Приводи, які втрачають декілька секторів, не завжди втрачають їх, але причиною цього є зазвичай широко використовуваний привід, який стає магнітно кашковим, або виходять з ладу голови / двигуни, що призводить до неточного чи невдалого читання / запису. Остаточне рішення, звичайно, залежить від вас: виходячи з цінності даних на накопичувачі та надійності, необхідної для систем, на яких ви працюєте, ви можете вирішити їх не змінювати. У мене є кілька накопичувачів з відомими поганими блоками, які роками обертаються застереженнями SMART у моєму файловому сервері, але вони створюють резервні копії за графіком, щоб я міг впоратися з повним збоєм без особливого болю.

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

Опція -cпередбачає, скільки секторів триїду одночасно. Це може мати певний вплив на продуктивність, а ці показники можуть залежати від конкретної моделі диска.

2) write-mode test- На мій погляд, він перевірить лише наявність у вас жорсткої помилки або помилкової помилки (aka Silent Degradacija даних, бітова гниль, занепад носіїв пам’яті, сектори UNC)

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

Незважаючи на високу кореляцію, ми робимо висновок, що моделі, що базуються лише на SMART-параметрах, навряд чи будуть корисними для прогнозування окремих відмов диска.

Що стосується згадок інших щодо заміни диска - можливо, у вас не проблема з жорстким поганим диском, але Silent Degradacija даних (бітова гниль, занепад носіїв пам’яті, сектори UNC). У такому випадку замінювати диск немає сенсу, але замість цього корисно виконувати читання / запис одних і тих же даних назад на диск. Ви можете подивитися тут, як це можна було б вирішити.

Якщо у вас є сильна помилка, ви можете спробувати переділити диск так, щоб погана область знаходилася поза будь-якими розділами. Для мене такий підхід був корисним, і такий поганий привід використовувався довго без проблем.

Я б залишив -b і -c за замовчуванням, якщо у вас немає конкретної причини змінити їх. Можливо, ви можете встановити -b до 4096, якщо ваш диск має розмір блоку 4k.

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

Нарешті, скільки перерозподілів секторів SMART є прийнятними / повинні бути негайно замінені диски з ненульовими підрахунками перерозподілу?

Я би замінив накопичувач, як тільки сектори будуть замінені.

Цей вид залежить від різниці між режимом читання поганих блоків (неруйнівним) та режимом запису (деструктивним):

Привід перерозподіляє поганий сектор лише тоді, коли запис не вдається. Помилки читання файлів "виправляються" лише тоді, коли робиться спроба перезаписати файл. Інакше. поганий блок залишається частиною файлу за умови, що ви можете щось відновити. Помилки читання для таблиць розділів можна "виправити" лише за допомогою запущених блоків у режимі запису та відтворення розділу

Отже, режим читання підкаже вам, де погані блоки, але нічого з цим зробити не можна. Режим запису перевіряє стан здоров'я кожного сектора і призведе до того, що диск буде виділяти поганий блок, але за рахунок знищення даних. Візьміть свій вибір.

Щоб відповісти на ваше друге запитання про переоформлені сектори, залежить. Я кажу з контексту домашнього користувача, який (періодично) контролює подібні речі.

• Наскільки критичні дані, що зберігаються на диску?
• Що втрачається, якщо привід раптом йде животом вгору?
• Чи є резервні дані в іншому місці?
• Чи привід є членом RAID, де втрати накопичувача мають мінімальний вплив?
• Чи зростає кількість переобладнаних секторів?

Ось дві ситуації, з якими я стикався. У мене був RAID5 на 6 дисках 200 Гб. Після відключення електроенергії, що призвело до мерехтливих вогнів, один привід показав 14 перероблених секторів та зафіксував кілька помилок. Я спостерігав за приводом, і більше помилок не було зафіксовано, і кількість перероблених секторів залишалася стабільною. Я зробив висновок, що привід страждав через перехідну потужність і не був інакше несправним. Я продовжував його використовувати протягом багатьох років. Оригінальний RAID5 був звільнений, але у мене є два таких накопичувачі, які працюють близько 10 років на години. У них є кілька перероблених секторів. Я використовую два з них дзеркально, щоб зберігати додаткові резервні копії з моєї основної резервної копії. Таким чином, основне резервне копіювання бачить (в основному) операції зчитування, а записи збираються на різних пристроях. Якщо один із цих древніх приводів виходить з ладу, інший повинен продовжувати дію. Якщо обидва не вдається, Я замінюю їх чимось іншим і повторюю сценарій резервного копіювання. Ефект, якщо один з цих накопичувачів вийде з ладу, становить майже нуль, тому я не переживаю за переобладнані сектори.

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

У мене був збій з накопичувачем на моєму первинному сервері резервних файлів. У ньому не було вдосконаленого попередження, воно просто перестало реагувати на команди SATA. Він був членом ZFS RAIDZ2, і я замінив його без жодної драми. Насправді на своєму тестовому сервері я замінив несправні диски без перемикання живлення або перезавантаження сервера.

Ще один момент, який слід зазначити, у мене є резервне копіювання всіх важливих даних на сайті та поза ним. Якщо якась одна система загублена, є дві копії даних в іншому місці.