Чи поганий сектор вказує на несправний диск?

Моя система Ubuntu 13.10 працювала дуже погано протягом останнього дня. Переглядаючи журнали ядра, виявляється, що <1-річний старий 3-ти TB-диск SATA має проблеми з певним сектором:

Nov  4 20:54:04 mediaserver kernel: [10893.039180] ata4.01: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
Nov  4 20:54:04 mediaserver kernel: [10893.039187] ata4.01: BMDMA stat 0x65
Nov  4 20:54:04 mediaserver kernel: [10893.039193] ata4.01: failed command: READ DMA EXT
Nov  4 20:54:04 mediaserver kernel: [10893.039202] ata4.01: cmd 25/00:08:f8:3f:83/00:00:af:00:00/f0 tag 0 dma 4096 in
Nov  4 20:54:04 mediaserver kernel: [10893.039202]          res 51/40:00:f8:3f:83/40:00:af:00:00/10 Emask 0x9 (media error)
Nov  4 20:54:04 mediaserver kernel: [10893.039207] ata4.01: status: { DRDY ERR }
Nov  4 20:54:04 mediaserver kernel: [10893.039211] ata4.01: error: { UNC }
Nov  4 20:54:04 mediaserver kernel: [10893.148527] ata4.00: configured for UDMA/133
Nov  4 20:54:04 mediaserver kernel: [10893.180322] ata4.01: configured for UDMA/133
Nov  4 20:54:04 mediaserver kernel: [10893.180345] sd 3:0:1:0: [sdc] Unhandled sense code
Nov  4 20:54:04 mediaserver kernel: [10893.180349] sd 3:0:1:0: [sdc]
Nov  4 20:54:04 mediaserver kernel: [10893.180353] Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE
Nov  4 20:54:04 mediaserver kernel: [10893.180356] sd 3:0:1:0: [sdc]
Nov  4 20:54:04 mediaserver kernel: [10893.180359] Sense Key : Medium Error [current] [descriptor]
Nov  4 20:54:04 mediaserver kernel: [10893.180371] Descriptor sense data with sense descriptors (in hex):
Nov  4 20:54:04 mediaserver kernel: [10893.180373]         72 03 11 04 00 00 00 0c 00 0a 80 00 00 00 00 00
Nov  4 20:54:04 mediaserver kernel: [10893.180384]         af 83 3f f8
Nov  4 20:54:04 mediaserver kernel: [10893.180389] sd 3:0:1:0: [sdc]
Nov  4 20:54:04 mediaserver kernel: [10893.180393] Add. Sense: Unrecovered read error - auto reallocate failed
Nov  4 20:54:04 mediaserver kernel: [10893.180396] sd 3:0:1:0: [sdc] CDB:
Nov  4 20:54:04 mediaserver kernel: [10893.180398] Read(16): 88 00 00 00 00 00 af 83 3f f8 00 00 00 08 00 00
Nov  4 20:54:04 mediaserver kernel: [10893.180412] end_request: I/O error, dev sdc, sector 2944614392
Nov  4 20:54:04 mediaserver kernel: [10893.180431] ata4: EH complete

kern.logФайл навколо 33MB основному сповнений помилок вище неодноразових і сектор не з'являється буде відрізнятися в неодноразових повідомленнях.

На даний момент я виконую наступну команду на відключеному диску для тестування та спроби розібратися з будь-якими проблемами, які може виникнути на диску. Я близько 12 годин і очікую, що це займе ще 24/48 годин, оскільки диск настільки великий:

e2fsck -c -c -p -v /dev/sdc1

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

Швидке оновлення!

e2fsck нарешті закінчився через 2 дні з великою кількістю "багаторазово заявлених блоків в inode". Спроба встановити файлову систему призвела до помилки, змушуючи її повернутися до режиму лише для читання:

Nov 11 08:29:05 mediaserver kernel: [211822.287758] EXT4-fs (sdc1): warning: mounting fs with errors, running e2fsck is recommended
Nov 11 08:29:05 mediaserver kernel: [211822.301699] EXT4-fs (sdc1): mounted filesystem with ordered data mode. Opts: errors=remount-ro

Спроба прочитати сектор вручну:

sudo dd count=1 if=/dev/sdc of=/dev/null skip=2944614392
dd: reading ‘/dev/sdc’: Input/output error
0+0 records in
0+0 records out
0 bytes (0 B) copied, 5.73077 s, 0.0 kB/s

Спроба написати це:

sudo dd count=1 if=/dev/zero of=/dev/sdc seek=2944614392
dd: writing to ‘/dev/sdc’: Input/output error
1+0 records in
0+0 records out
0 bytes (0 B) copied, 2.87869 s, 0.0 kB/s

За обома підрахунками Reallocated_Sector_Ctзалишилось 0.

Привід переходить у стан сну досить часто. Я зараз думаю, що це може бути проблемою файлової системи? Я не на 100%.

Погані сектори завжди є вказівкою на збій жорсткого диска, адже в момент, коли ви бачите помилку вводу / виводу, таку як ця, ви, ймовірно, вже втратили / пошкодили деякі дані. Зробіть резервну копію, якщо у вас її ще немає, проведіть самотест smartctl -t long /dev/diskі перевірте дані SMART smartctl -a /dev/disk. Отримайте заміну, якщо зможете.

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

Щоб зробити потяг до перерозподілу секторів, зазвичай потрібно щось написати в них. Однак, dd( D ISK D estroyer) не завжди працює, і дуже небезпечно: якщо ви змішуєте skipі seekваріанти, ви можете легко знімати себе в нозі, skipпінг в Nперші блоках /dev/zeroі запис блоку від цього «зміщення» над сектор 0 вашого жорсткого диска .

Якщо ви дійсно знаєте, що хочете змусити сектор перезаписати нулями, вам слід скористатися hdparm:

% sudo hdparm --read-sector 833192656 /dev/sda
/dev/sda:
reading sector 833192656: FAILED: Input/output error

Так, сектор 833192656 також провалився в смарт-тестах. Щоб записати до нього нулі, використовуйте --write-sector:

% sudo hdparm --write-sector 833192656 /dev/sda
/dev/sda:
Use of --write-sector is VERY DANGEROUS.
You are trying to deliberately overwrite a low-level sector on the media.
This is a BAD idea, and can easily result in total data loss.
Please supply the --yes-i-know-what-i-am-doing flag if you really want this.
Program aborted.

В якості гарантії hdparmнасправді нічого не пишуть, якщо ви не передасте --yes-i-know-what-i-am-doingкомутатор hdparm:

% sudo hdparm --yes-i-know-what-i-am-doing --write-sector 833192656 /dev/sda
/dev/sda:
re-writing sector 833192656: succeeded
% sudo hdparm --read-sector 833192656 /dev/sda                              

/dev/sda:
reading sector 833192656: succeeded
0000 0000 0000 0000 0000 0000 0000 0000
[      ... more zeroes here...        ]
0000 0000 0000 0000 0000 0000 0000 0000

%

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

Ви можете працювати badblocks -nна диску, щоб прочитати та переписати кожен сектор, або у вашому випадку, оскільки ви вже знаєте номер відповідного сектора, ви можете використовувати ddдля запису нулів до нього. Ви можете перевірити статистику SMART smartctl -a. Ви маєте побачити очікуване перерозподілене число, яке вказує, скільки секторів не вдалося прочитати, а після спроби записати сектор ця кількість зменшиться. Кількість перерозподілених секторів може збільшитися, і в цьому випадку це було фізично погано і було перезавантажено до запасного пулу, і це може бути ознакою того, що привід виходить назовні. Якщо ні, то тоді це було просто замішано і зараз має бути добре.

Спробуйте спочатку прочитати сектор:

dd count=1 if=/dev/sda of=/dev/null skip=nnnn

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

dd count=1 if=/dev/zero of=/dev/sda seek=nnnn

Переконайтесь, що ви ввели команду саме перед натисканням клавіші Enter.