Помилки читання на жорсткому диску, які… зупиняються?

Моя історія починається досить просто. У мене є легкий сервер із запуском Arch Linux, який зберігає більшість своїх даних на RAID-1, що складається з двох накопичувачів SATA. Він працював без проблем близько 4 місяців. Потім раптом я почав отримувати помилки читання на одному з накопичувачів. Завжди повідомлення виглядали приблизно так:

Apr 18 00:20:15 hope kernel: [307085.582035] ata5.01: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
Apr 18 00:20:15 hope kernel: [307085.582040] ata5.01: failed command: READ DMA EXT
Apr 18 00:20:15 hope kernel: [307085.582048] ata5.01: cmd 25/00:08:08:6a:34/00:00:27:00:00/f0 tag 0 dma 4096 in
Apr 18 00:20:15 hope kernel: [307085.582050]          res 51/40:00:0c:6a:34/40:00:27:00:00/f0 Emask 0x9 (media error)
Apr 18 00:20:15 hope kernel: [307085.582053] ata5.01: status: { DRDY ERR }
Apr 18 00:20:15 hope kernel: [307085.582056] ata5.01: error: { UNC }
Apr 18 00:20:15 hope kernel: [307085.621301] ata5.00: configured for UDMA/133
Apr 18 00:20:15 hope kernel: [307085.640972] ata5.01: configured for UDMA/133
Apr 18 00:20:15 hope kernel: [307085.640986] sd 4:0:1:0: [sdd] Unhandled sense code
Apr 18 00:20:15 hope kernel: [307085.640989] sd 4:0:1:0: [sdd]  Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE
Apr 18 00:20:15 hope kernel: [307085.640993] sd 4:0:1:0: [sdd]  Sense Key : Medium Error [current] [descriptor]
Apr 18 00:20:15 hope kernel: [307085.640998] Descriptor sense data with sense descriptors (in hex):
Apr 18 00:20:15 hope kernel: [307085.641001]         72 03 11 04 00 00 00 0c 00 0a 80 00 00 00 00 00 
Apr 18 00:20:15 hope kernel: [307085.641010]         27 34 6a 0c 
Apr 18 00:20:15 hope kernel: [307085.641020] sd 4:0:1:0: [sdd]  Add. Sense: Unrecovered read error - auto reallocate failed
Apr 18 00:20:15 hope kernel: [307085.641023] sd 4:0:1:0: [sdd] CDB: Read(10): 28 00 27 34 6a 08 00 00 08 00
Apr 18 00:20:15 hope kernel: [307085.641027] end_request: I/O error, dev sdd, sector 657746444
Apr 18 00:20:15 hope kernel: [307085.641035] ata5: EH complete
Apr 18 00:20:15 hope kernel: [307085.641672] md/raid1:md16: read error corrected (8 sectors at 657744392 on sdd1)
Apr 18 00:20:17 hope kernel: [307087.505082] md/raid1:md16: redirecting sector 657742336 to other mirror: sdd1

Кожна помилка скаржилася на інший номер сектору і супроводжувалася декількома секундами затримки для доступу користувача (мене) до диска.

Я перевірив висновок smartctl і побачив наступний вихід (невідповідні частини, вирізані):

ID# ATTRIBUTE_NAME          FLAG     VALUE WORST THRESH TYPE      UPDATED  WHEN_FAILED RAW_VALUE
  1 Raw_Read_Error_Rate     0x002f   193   193   051    Pre-fail  Always       -       1606
  5 Reallocated_Sector_Ct   0x0033   194   194   140    Pre-fail  Always       -       0
196 Reallocated_Event_Count 0x0032   162   162   000    Old_age   Always       -       0
197 Current_Pending_Sector  0x0032   200   200   000    Old_age   Always       -       51

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

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

У цей момент, цікаво дізнатися, чи погані сектори просто у непрацюючих частинах диска, я вийняв диск з RAID, поклав його назад в RAID і дозволив йому завершити наступне повне пересинхронізацію. Ресинхронізація завершена без жодних помилок через 9 годин (2 ТБ триває час).

Крім того, висновок smartctl трохи змінився:

ID# ATTRIBUTE_NAME          FLAG     VALUE WORST THRESH TYPE      UPDATED  WHEN_FAILED RAW_VALUE
  1 Raw_Read_Error_Rate     0x002f   193   193   051    Pre-fail  Always       -       1606
  5 Reallocated_Sector_Ct   0x0033   194   194   140    Pre-fail  Always       -       43
196 Reallocated_Event_Count 0x0032   162   162   000    Old_age   Always       -       38
197 Current_Pending_Sector  0x0032   200   200   000    Old_age   Always       -       0

Отже, частина цього, що мене дивно переживає, - це, звичайно, "з тих пір, коли погані диски виправляються самі?"

Я вважаю, що можливо, що дуже невелика площа накопичувача спонтанно вийшла з ладу, і що диск просто зайняв 3 дні (!), Перш ніж почався перерозподіл коду сектору, і він склав кілька запасних секторів на погану область диска ... Але я не можу сказати, що я коли-небудь бачив, щоб це сталося.

Хтось ще бачив подібну поведінку? Якщо так, то який у вас був досвід із диском згодом? Чи трапилось це знову? Чи зрештою диск повністю вийшов з ладу? Або це був просто незрозумілий глюк, який залишився незрозумілим?

У моєму випадку у мене вже є привід заміни (отриманий під гарантію), тому я, мабуть, просто замінюватиму диск. Але я хотів би знати, чи неправильно діагностував це. Якщо це допомагає, у мене є повний висновок 'smartctl -a', коли проблема виникала. Це зовсім небагато часу, тому я не публікував це тут.

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

Після того, як погані сектори будуть нанесені на карту, і поки більша частина приводної поверхні не вийде з ладу, ви в хорошій формі.

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

Більшість сучасних накопичувачів "викреслить" блок, який погано погіршився. У накопичувача є запасні блоки, і прошивка використовує їх для заміни блоків, які, як відомо, є поганими. Привід не може здійснити це повторне відображення, коли не вдається прочитати блок, оскільки він не може надати правильні дані. Він просто повертає "помилку читання". Він позначає БЕЗПЕЧЕННЯ блоку як поганий, тому якщо блок коли-небудь читає правильно, то блок перевіряється і правильні дані записуються в блок заміни. Якщо ОС коли-небудь ПИСЬМО в блок, який знаходиться в стані "перебуває в очікуванні", тоді блок векторується, а дані записуються в блок заміни.

Після нальоту програмного забезпечення Linux, отримавши помилку читання з пристрою, отримає правильні дані з інших елементів масиву, а потім знову спробує ЗАПИСИТИ поганий блок. Так, якщо запис працює нормально, то дані є безпечними, якщо ні, то привід виконує вищезазначене, векторує блок, а потім виконує запис. Так, привід за допомогою набіжної системи щойно відремонтував себе!

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

Так, я це бачив і за дуже схожих обставин. У моєму випадку саме цей "трюк" на мене потягнув "Зелений" диск "Western Digital" 1 ТБ "WD10EARS". Значення SMART- Current_Pending_Sectorсировини пішло від нуля до 6, а потім до 8, спонукаючи демона моніторингу SMART надіслати мені зловісні електронні листи.

Я mdadm --failредагував і --removeзапускав диск з масиву і пропускав неруйнівний прохід badblocksпо ньому, і так, мабуть, було понад 2 десятки поганих блоків. Коли приблизно через день прийшов замінний привід, я виправив масив, і життя продовжувалося.

Незабаром після цього, з нудьги, я знову переїхав badblocksна "невдалий" диск, щоб побачити, чи погіршився він. Навпаки, привід повністю "відремонтував" себе: нуль поганих блоків! Похитавши головою, я витер її і відклав, щоб її переробили або подарували.

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

Загальна практика в серверних середовищах відкидати диски, які коли-небудь показували такі помилки, виправлені чи ні. Жорсткі помилки в секторі можуть бути ознакою фізичного пошкодження поверхні середовища - і якщо ви подряпаєте поверхню, ви зазвичай або зміщуєте матеріал в сторони подряпини, і отримуєте задирок вище площини такої поверхні - або абразивний пил (скло! ). Обидва, як правило, досить згубно впливають на механічну систему, яка спирається на дуже тонку повітряну подушку між двома поверхнями, яка вважається ідеально гладкою ... ось чому середні помилки, коли вони починають досягати певного підрахунку, мають тенденцію до швидшого розмноження.