Як отримати всі збійні сектори на диску

[gdekjifgb]

Мова йдеться не про витягування даних із збійних секторів а про ідентифікування таких секторів. Надибав "мертвий диск". В логах "випадково" знайшов

Код: [Вибрати]

[  104.368089] blk_update_request: I/O error, dev sdc, sector 4096
[  104.368121] blk_update_request: I/O error, dev sdc, sector 4096
[  108.548126] blk_update_request: I/O error, dev sdc, sector 436273408
[  108.548145] blk_update_request: I/O error, dev sdc, sector 436274432
[  108.548156] blk_update_request: I/O error, dev sdc, sector 436275456
[  108.548166] blk_update_request: I/O error, dev sdc, sector 436276480
[  113.824081] blk_update_request: I/O error, dev sdc, sector 486805504
[  113.824121] blk_update_request: I/O error, dev sdc, sector 486805504
[  113.824124] blk_update_request: I/O error, dev sdc, sector 486805504
[  133.829834] blk_update_request: I/O error, dev sdc, sector 78088
[  133.829880] blk_update_request: I/O error, dev sdc, sector 4096
[  133.829883] blk_update_request: I/O error, dev sdc, sector 4096
[  133.829914] blk_update_request: I/O error, dev sdc, sector 78088
[  133.829934] blk_update_request: I/O error, dev sdc, sector 4096
[  133.829936] blk_update_request: I/O error, dev sdc, sector 4096
[  152.092394] blk_update_request: I/O error, dev sdc, sector 78088
[  152.092435] blk_update_request: I/O error, dev sdc, sector 4096
[  152.092437] blk_update_request: I/O error, dev sdc, sector 4096
[  152.127757] blk_update_request: I/O error, dev sdc, sector 78088
Зробив два розділи на диску, виключиивши (оминувши) збйні сектори, і сталося чудо. Диск працює без помилок. Критичнчі дані на ньому зберігати не буду.

Хотілось би знати всі мертві сектори. як і яим це можна  хробити? Одна ідея є - спродувати записати на увесь диск нулі -  під час запису воно повинно сказати про мертві сектори. а іще як можна це зробити?

[Миха́йло Даниле́нко]

Для більшості сучасних дисків:

Код: [Вибрати]

smartctl -t short /dev/sdX
sleep $((60*5))
smartctl -l selftest /dev/sdXЯкщо у виводі є LBA_of_first_error — це bb. Якщо немає — то те ж саме з -t long. Ну і почекати не 5 хвилин, а скільки скаже, зазвичай близько 2 годин.
 Пробуєте перезаписати знайдений bb. Контроллер має при перезаписі зробити reallocate, і сектор повинен ожити. Якщо reallocate зробити не вдасться — значить зарезервоване виробником місце скінчилося, і цей метод вам не допоможе.

Альтернативно —

Код: [Вибрати]

dd if=/dev/zero of=/dev/sdXАле так вам доведеться парсити вивід ядра, ну і є вірогідність забити собі все місце в системі гігантським логом.

[gdekjifgb]

Якщо у виводі є LBA_of_first_error ...

спробую...

[prapor]

https://whdd.github.io/
Дозволить виявити ще й ті блоки, що наразі «живі», але «вже скоро».

[gdekjifgb]

https://whdd.github.io/
Дозволить виявити ще й ті блоки, що наразі «живі», але «вже скоро».

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

Завршення роботи dd до кінця не чекав. Про бб нічого не пише.

Запустив badblocks

Код: [Вибрати]

badblocks -s -v -w  -f -t random /dev/sdb
але з 8 числа нема згадок про бедблоки.

Код: [Вибрати]

Nov  8 03:50:12 localhost kernel: [  755.408377] blk_update_request: I/O error, dev sdc, sector 976771048це найсвіжіше повідомлення про бблоки. Дивно. Треба покопіювати на диск всякого, може виявляться іще якісь збійні.

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

оце 250 гб.

Код: [Вибрати]

/var/log# smartctl -A /dev/sdc
smartctl 6.2 2013-07-26 r3841 [x86_64-linux-4.4.0-62-generic] (local build)
Copyright (C) 2002-13, Bruce Allen, Christian Franke, www.smartmontools.org

=== START OF READ SMART DATA SECTION ===
SMART Attributes Data Structure revision number: 10
Vendor Specific SMART Attributes with Thresholds:
ID# ATTRIBUTE_NAME          FLAG     VALUE WORST THRESH TYPE      UPDATED  WHEN_FAILED RAW_VALUE
  1 Raw_Read_Error_Rate     0x000f   100   253   006    Pre-fail  Always       -       0
  3 Spin_Up_Time            0x0003   096   095   000    Pre-fail  Always       -       0
  4 Start_Stop_Count        0x0032   091   091   020    Old_age   Always       -       9458
  5 Reallocated_Sector_Ct   0x0033   100   100   036    Pre-fail  Always       -       0
  7 Seek_Error_Rate         0x000f   087   060   030    Pre-fail  Always       -       607279654
  9 Power_On_Hours          0x0032   051   051   000    Old_age   Always       -       43620
 10 Spin_Retry_Count        0x0013   100   099   097    Pre-fail  Always       -       0
 12 Power_Cycle_Count       0x0032   091   091   020    Old_age   Always       -       9726
187 Reported_Uncorrect      0x003a   083   083   000    Old_age   Always       -       17
189 High_Fly_Writes         0x0022   100   100   000    Old_age   Always       -       0
190 Airflow_Temperature_Cel 0x001a   063   041   000    Old_age   Always       -       37 (Min/Max 15/39)
194 Temperature_Celsius     0x0000   037   059   000    Old_age   Offline      -       37 (0 8 0 0 0)
195 Hardware_ECC_Recovered  0x0032   080   056   000    Old_age   Always       -       148740131
197 Current_Pending_Sector  0x0000   100   100   000    Old_age   Offline      -       0
198 Offline_Uncorrectable   0x0000   100   100   000    Old_age   Offline      -       0
199 UDMA_CRC_Error_Count    0x0000   200   200   000    Old_age   Offline      -       2

Через Seek_Error_Rate , при зверненні до диску він шось бурмотить. мабутоь скаржиться що йому ліньки шукати дані.

а оце 500 гб, який тестую

Код: [Вибрати]

/var/log# smartctl -A /dev/sdb
smartctl 6.2 2013-07-26 r3841 [x86_64-linux-4.4.0-62-generic] (local build)
Copyright (C) 2002-13, Bruce Allen, Christian Franke, www.smartmontools.org

=== START OF READ SMART DATA SECTION ===
SMART Attributes Data Structure revision number: 16
Vendor Specific SMART Attributes with Thresholds:
ID# ATTRIBUTE_NAME          FLAG     VALUE WORST THRESH TYPE      UPDATED  WHEN_FAILED RAW_VALUE
  1 Raw_Read_Error_Rate     0x000b   100   100   016    Pre-fail  Always       -       0
  2 Throughput_Performance  0x0005   130   130   054    Pre-fail  Offline      -       153
  3 Spin_Up_Time            0x0007   120   120   024    Pre-fail  Always       -       335 (Average 302)
  4 Start_Stop_Count        0x0012   099   099   000    Old_age   Always       -       4821
  5 Reallocated_Sector_Ct   0x0033   088   088   005    Pre-fail  Always       -       377
  7 Seek_Error_Rate         0x000b   100   100   067    Pre-fail  Always       -       0
  8 Seek_Time_Performance   0x0005   131   131   020    Pre-fail  Offline      -       29
  9 Power_On_Hours          0x0012   099   099   000    Old_age   Always       -       13267
 10 Spin_Retry_Count        0x0013   100   100   060    Pre-fail  Always       -       0
 12 Power_Cycle_Count       0x0032   099   099   000    Old_age   Always       -       4808
192 Power-Off_Retract_Count 0x0032   096   096   000    Old_age   Always       -       4822
193 Load_Cycle_Count        0x0012   096   096   000    Old_age   Always       -       4822
194 Temperature_Celsius     0x0002   162   162   000    Old_age   Always       -       37 (Min/Max 8/44)
196 Reallocated_Event_Count 0x0032   062   062   000    Old_age   Always       -       824
197 Current_Pending_Sector  0x0022   100   100   000    Old_age   Always       -       0
198 Offline_Uncorrectable   0x0008   100   100   000    Old_age   Offline      -       0
199 UDMA_CRC_Error_Count    0x000a   200   200   000    Old_age   Always       -       3011

незн.,  дочекаюсь закінчення тесту.  Для зберігання відеоуроків згодиться.

Вже не буду довіряти badblocks

Код: [Вибрати]

/var/log# badblocks -s -v -w  -f -t random /dev/sdb
Checking for bad blocks in read-write mode
From block 0 to 488385526
Testing with random pattern: done                                                 
Reading and comparing: done                                                 
Pass completed, 0 bad blocks found. (0/0/0 errors)

Лише gnome-disks пише що на диску є 377 пошкоджених сектора.

[Миха́йло Даниле́нко]

Боже, що ви з тими дисками робите? Чого у них таке велике відношення power_cycle_count/power_on_hours? Хоча можливо я просто давно не стикався з класичними робочими станціями...

Власне, я підозрюю, що контроллер диска вже подбав про bb (тобто зробив reallocate). До речі, іноді проблеми io можуть бути викликані не самими дисками, а кабелями sata.

[gdekjifgb]

Боже, що ви з тими дисками робите? Чого у них таке велике відношення power_on_hours/power_cycle_count? ...

незнаю. ось що на ssd показує (і вже є 2 релока)

Код: [Вибрати]

=== START OF READ SMART DATA SECTION ===
SMART Attributes Data Structure revision number: 1
Vendor Specific SMART Attributes with Thresholds:
ID# ATTRIBUTE_NAME          FLAG     VALUE WORST THRESH TYPE      UPDATED  WHEN_FAILED RAW_VALUE
  1 Raw_Read_Error_Rate     0x0000   100   100   050    Old_age   Offline      -       0

  5 Reallocated_Sector_Ct   0x0002   100   100   050    Old_age   Always       -       0

  9 Power_On_Hours          0x0000   100   100   050    Old_age   Offline      -       3074
 12 Power_Cycle_Count       0x0000   100   100   050    Old_age   Offline      -       2379

160 Unknown_Attribute       0x0000   100   100   050    Old_age   Offline      -       0
161 Unknown_Attribute       0x0000   100   100   050    Old_age   Offline      -       55
162 Unknown_Attribute       0x0000   100   100   050    Old_age   Offline      -       1
163 Unknown_Attribute       0x0000   100   100   050    Old_age   Offline      -       13
164 Unknown_Attribute       0x0000   100   100   050    Old_age   Offline      -       7310608
165 Unknown_Attribute       0x0000   100   100   050    Old_age   Offline      -       14558
166 Unknown_Attribute       0x0000   100   100   050    Old_age   Offline      -       14506
167 Unknown_Attribute       0x0000   100   100   050    Old_age   Offline      -       14306
192 Power-Off_Retract_Count 0x0000   100   100   050    Old_age   Offline      -       1388
194 Temperature_Celsius     0x0000   100   100   050    Old_age   Offline      -       28
195 Hardware_ECC_Recovered  0x0000   100   100   050    Old_age   Offline      -       9959
196 Reallocated_Event_Count 0x0000   100   100   050    Old_age   Offline      -       0
199 UDMA_CRC_Error_Count    0x0000   100   100   050    Old_age   Offline      -       25
241 Total_LBAs_Written      0x0000   100   100   050    Old_age   Offline      -       105306
242 Total_LBAs_Read         0x0000   100   100   050    Old_age   Offline      -       184764
245 Unknown_Attribute       0x0000   100   100   050    Old_age   Offline      -       22813037

---

...
Власне, я підозрюю, що контроллер диска вже подбав про bb (тобто зробив reallocate). До речі, іноді проблеми io можуть бути викликані не самими дисками, а кабелями sata.

Раніше диск був з віндою (я раніше здається колись на форумі писав про нього). Був він у юзера який цілими днями і ночами грається в танчики.   І раптом у нього почалися глюки з грою (тому що почали зникати або не зчитуватись файли). Юзер спочатку за... довбав всю тех підтримку... 

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

оот... , для чого я це пишу? Нещодавно був у того ґ-юзера. У вінд системі таке екзотичне пз понаставляв, просто піпєц.

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

Запитав у нього "Що це?"

"Мені в техподдєржкє сказали поставити..."

---
ну ото такі справи. ааа, бл., про головне ледь не забув. Взяв я у нього цей "негодний" диск.
Питання: Чому саме у мене фірмварь (МАБУТЬ) зарелокейтив (порелокейтив) бедблоки?
---

Зараз пишу нулі у файл, попередньо зробивши один розділ  на увесь диск. бо робив два, виключаючи збійні сектори.

Дивно, але помилок нема.
---

Edit:

Коли тільки підключав до системника, то думав що можливо сата роз’єми капризні. Але підкючивши на місце ссд, отримував картину з бедами.

Зараз все дуже дивно,  в логах також нема згадувань про "ata,  sdX, sector"

Код: [Вибрати]

/var/log# dd if=/dev/zero of=/media/xuser/500/500.gb bs=512
dd: ошибка записи «/media/xuser/500/500.gb»: На устройстве не осталось свободного места
976226161+0 записей получено
976226160+0 записей отправлено
скопировано 499827793920 байт (500 GB), 6109,08 c, 81,8 MB/c
ну що ж - буду користуватись 

[prapor]

Боже, що ви з тими дисками робите? Чого у них таке велике відношення power_cycle_count/power_on_hours? Хоча можливо я просто давно не стикався з класичними робочими станціями...

То може бути WD Green. У них бага — вони паркують головки коли неактивні кілька секунд. Зазвичай, цей час неактивності трохи менше, ніж інтервали скидання кешу у Linux. Але у WD Green вони зробили свого часу цей таймаут таким, що під будь-якою системою воно постійно паркує головки. За годину роботи отримати кілька десятків паркувань там у порядку речей.

P.S. Коли кількість Reallocate Event значно перевищує кількість Realocated Sector, особисто я отримую два потужні магніти та геліограф. Або вертаю диск по гарантії.

[gdekjifgb]

То може бути WD Green. ...

P.S. Коли кількість Reallocate Event значно перевищує кількість Realocated Sector, особисто я отримую два потужні магніти та геліограф. Або вертаю диск по гарантії.

Ніколи не мав справ із green-серіями, бо у них 5400 обертів і надійність ніяка. Хоча хйзн., може воно і green(?).


Model Family:     Hitachi Deskstar P7K500
Device Model:     Hitachi HDP725050GLA360

і іще древніший
Model Family:     Seagate Barracuda ES
Device Model:     ST3250620NS

---
дописую: 8 числа результат 2-3 хвилин роботи whdd був ддуужжее не хорошим. А зараз див скрін.

команда  smartctl -l error (і selftest) /dev/sdb показує багато помилок.

Все. Тему, мабуть, закрито.