Очікуваний нечитабельний сектор - це той, який повернув помилку читання і який привід позначив для перезапису при першій можливій нагоді. Однак він не може зробити перепланування, поки не відбудеться одна з двох речей:
- Сектор успішно перечитується
- Сектор переписаний
До цього часу сектор залишається в очікуванні. Отже, у вас є два відповідні способи впоратися з цим:
- Продовжуйте намагатися перечитувати сектор, поки вам це не вдасться
- Перезапишіть цей сектор новими даними
Очевидно, що (1) є не руйнівним, тому, ймовірно, слід спробувати спершу, хоча майте на увазі, що якщо накопичувач серйозно починає виходити з ладу, то постійне зчитування з поганої області, швидше за все, вийде з ладу набагато швидше . Якщо у вас багато секторів, що очікують на розгляд, та інших помилок, і ви дбаєте про дані на диску, рекомендую вийняти їх із сервісу та використовувати відмінний інструмент ddrescue, щоб відновити якомога більше даних. Потім відмовтеся від приводу.
Якщо відповідний сектор містить дані, які вас не цікавлять, або ви можете відновити їх із резервної копії, то його перезапис, мабуть, є найшвидшим та найпростішим рішенням. Потім ви можете переглянути перерозподілені та очікувані рахунки для накопичувача, щоб переконатися, що за цим сектором доглядають.
Як дізнатися, що відповідає сектору у файловій системі? Я знайшов відмінну статтю на Smartmontools веб - сайті, тут , хоча це досить технічні і специфічно для ext2 / 3/4 і файлових систем Райзера.
Більш простий підхід, який я використовував на одному з моїх власних (Mac) дисків, - це використовувати find / -xdev -type f -print0 | xargs -0 ...для читання кожного файлу в системі. Запишіть підрахунок очікувань перед тим, як запустити це. Якщо сектор знаходиться у файлі, ви отримаєте повідомлення про помилку з інструменту, за допомогою якого ви читали файли (наприклад, md5sum), що показує вам шлях до нього. Потім ви можете зосередити свою увагу на повторному читанні лише цього файлу, поки він не буде успішно прочитаний. Часто це вирішить проблему, якщо це нечасто використаний файл, який просто потрібно було перечитати кілька разів. Якщо помилка усувається або у вас не виникають помилки при читанні всіх файлів, перевірте кількість очікувань, щоб побачити, чи зменшилась вона. Якщо є, проблема була вирішена читанням.
Якщо файл не може бути успішно прочитаний після декількох спроб (наприклад, 20), тоді вам потрібно перезаписати файл або блок у файлі, щоб диск дозволив перерозподілити сектор. Ви можете використовувати ddrescue у файлі (а не на розділі), щоб перезаписати лише один сектор, скопіювавши його у тимчасовий файл та знову скопіювавши назад. Зауважте, що просто видалити файл у цей момент - погана ідея, оскільки поганий сектор потрапить у вільний список, де його буде важче знайти. Повністю перезаписати це теж погано, тому що знову сектори потраплять у вільний список. Вам потрібно переписати наявні блоки. notruncВаріант ddє одним з способів зробити це.
Якщо ви не зіткнулися з помилками, а кількість очікувань не зменшилася, сектор повинен бути у вільному списку або в частині інфраструктури файлової системи (наприклад, таблиця inode). Ви можете спробувати заповнити весь вільний простір cat /dev/zero >tempfile, а потім перевірити кількість відкладених. Якщо вона знизиться, проблема була у вільному списку і тепер пішла.
Якщо сектор знаходиться в інфраструктурі, у вас є більш серйозна проблема, і ви, мабуть, зіткнетеся з помилками, просто переходячи до дерева каталогів. У цій ситуації я думаю, що єдине розумне рішення - це переформатувати накопичувач, необов'язково використовуючи ddrescue для відновлення даних, якщо це необхідно.
Уважно стежте за приводом. Перерозподіл сектору - це дуже хороший канар у вугільній шахті , що потенційно може попереджати про аварійний привід. Вживши ранніх заходів, ви можете запобігти подальшому катастрофічному та дуже болючому зсуву. Я не припускаю, що кілька перерозподілів секторів є ознакою того, що слід відмовитися від накопичувача. Усі сучасні накопичувачі повинні зробити певну перерозподіл. Однак якщо накопичувач не дуже старий (<1 рік) або у вас часті нові перерозподіли (> 1 / місяць), то рекомендую замінити його якнайшвидше.
Я не маю емпіричних доказів, щоб це підтвердити, але мій досвід говорить про те, що проблеми з дисками можна зменшити, читаючи весь диск раз за часом, або ddз необробленого диска, або з допомогою читання кожного файлу за допомогою find. Майже всі проблеми з диском, з якими я стикався за останні кілька років, спочатку з’явилися у рідко використовуваних файлах або на машинах, які не використовуються багато. Це має сенс евристично також у тому, що якщо сектор часто читається, привід має шанс перерозподілити його, коли він вперше виявить незначну проблему з цим сектором, а не чекає, поки сектор повністю не читається. Привід не може нічого робити із сектором, якщо хост якось не звертається до нього, чи читаючи чи записуючи його чи проводячи один із тестів SMART.
Я хотів би поекспериментувати з ідеєю нічної або щотижневої роботи з крон, яка читає весь диск. В даний час я використовую RAID "бідного чоловіка", в якому у мене є другий жорсткий диск в машині, і я створюю резервну копію основного диска на нього щовечора. У чомусь це насправді краще, ніж дзеркальне відображення в RAID, тому що якщо я помиляю і видаляю файл помилково, я можу отримати негайно вчорашню версію з резервного диска. З іншого боку, я вважаю, що апаратний RAID-контролер робить багато хорошої роботи у фоновому режимі, щоб відстежувати, повідомляти та виправляти проблеми з диском під час їх появи. Мій поточний скрипт резервного копіювання використовує rsyncдля уникнення копіювання даних, які не змінилися, але з огляду на необхідність перечитувати всі сектори, можливо, було б краще скопіювати все, або мати окремий скрипт, який щотижня читає весь неочищений диск.