LINUX.ORG.RU
ФорумAdmin

Какие в Линуксе есть средства поиска/ремапа бэдов на винтах?

 , ,


3

6

Надеюсь здесь найдётся пруфлинк с описанием этой операции.
Можно конечно качнуть флэшку с виндой и Викторией. Но неужели это не исполнимо в Линукс? Или местные адепты начну топырить пальцы: «Если на винте попался бэд - ф памойку такой винт»?

P.S. Резюмирую, после пальцетопырчатого срача от «крутых» пацанов, благодаря комментариям порядочных гуру - решил проблему просто:

Для начала собрал список «битых» файлов:

find ./ -type f -exec cat '{}' \; |pv|dd of=/dev/null

Список файлов получил на консоль и скопировал в лог, выделив и скопипастив.
Предлагаю попробовать другой вариант:
find ./ -type f -exec cat '{}' \; >/dev/null 2>Errors.log

Но в этом варианте не будет прогресс-индикатора, зато список «битых» файлов должен получиться в файле.

Далее сделал список плохих секторов командой:
badblocks -o badblocks.log /dev/sdX

В этом файле - плохие блоки были сериями. Для каждой серии сначала проверил:
badblocks -o 01set.log /dev/sdX <LastBlock> <FirstBlock>

Получал список блоков этого диапазона.
Далее затирал эти блоки нулями:
badblocks -f -w /dev/sdX <LastBlock> <FirstBlock>

Снова проверял:
badblocks -o 01set.log /dev/sdX <LastBlock> <FirstBlock>
Получал пустой список - т.е. блоки исправились.

Теперь запустил:
smartctl -t long и по его результатам допишу.

НИКАКОГО РЕМАПА! Просто перезаписал данные в нечитаемые сектора!
Ну и опять прогоню рекурсивное чтение файлов, данные конечно неправильные, но ошибок быть не должно.
И на этом диске zfs, посмотрю что скажет: zpool scrub

P.P.S. Результаты -t long:
SMART Self-test log structure revision number 1
Num  Test_Description    Status                  Remaining  LifeTime(hours)  LBA_of_first_error
# 1  Extended offline    Completed: read failure       40%     39752         3352487288

Проверяем:
badblocks -o 07-sdd-badblocks.log /dev/sdd 3352488289 3352487288

Но! Факир был пьян! SMART и BADBLOCKS видимо оперируют разными размерами сектора!
# badblocks -o 07-sdd-badblocks.log /dev/sdd 3352488289 3352487288
badblocks: Недопустимый аргумент during seek
badblocks: Недопустимый аргумент during seek
badblocks: Недопустимый аргумент during seek
badblocks: Недопустимый аргумент during seek
badblocks: Недопустимый аргумент during seek
badblocks: Недопустимый аргумент during seek
badblocks: Недопустимый аргумент during seek
badblocks: Недопустимый аргумент during seek
badblocks: Недопустимый аргумент during seek
badblocks: Недопустимый аргумент during seek
badblocks: Недопустимый аргумент during seek
badblocks: Недопустимый аргумент during seek
badblocks: Недопустимый аргумент during seek
badblocks: Недопустимый аргумент during seek
badblocks: Недопустимый аргумент during seek
badblocks: Недопустимый аргумент during seek

Придётся повторить badblocks и посмотреть его видение!

★★★

Последнее исправление: n0mad (всего исправлений: 8)
Ответ на: комментарий от legolegs

рекурсивно читать всё содержимое fs и вести журнал с ошибками чтения

find /mnt/foobar -type f -exec cat {} \; > /dev/null 2> error.log
Ты какие-то слишком простые вопросы задаёшь.

Ну забываю, неделя мозговой комы, даёт о себе знать.
Но я предпочитаю (прошелся по своим скриптам):
find ./ -type f -exec cat '{}' \; |pv|dd of=/dev/null
Так он показывает и скорость и время и прогресс. Но вот про 2>error.log я не задумался. Сейчас добавлю в свой старый скрипт. И >/dev/null вместо dd - тоже попробую. Мне почему то казалось что через dd быстрее.

n0mad ★★★
() автор топика
Ответ на: комментарий от ALiEN175

А покажите-ка смарт диска. Так, чисто интересно.

Ща наспамлю... в одно сообщение оно не влазит...

smartctl 7.3 2022-02-28 r5338 [x86_64-linux-6.1.0-33-amd64] (local build)
Copyright (C) 2002-22, Bruce Allen, Christian Franke, www.smartmontools.org

=== START OF INFORMATION SECTION ===
Model Family:     Toshiba 3.5" DT01ACA... Desktop HDD
Device Model:     TOSHIBA DT01ACA300
Serial Number:    Z7P6GLWAS
LU WWN Device Id: 5 000039 fe6df2013
Firmware Version: MX6OABB0
User Capacity:    3 000 592 982 016 bytes [3,00 TB]
Sector Sizes:     512 bytes logical, 4096 bytes physical
Rotation Rate:    7200 rpm
Form Factor:      3.5 inches
Device is:        In smartctl database 7.3/5319
ATA Version is:   ATA8-ACS T13/1699-D revision 4
SATA Version is:  SATA 3.0, 6.0 Gb/s (current: 3.0 Gb/s)
Local Time is:    Mon Apr 21 19:06:13 2025 MSK
SMART support is: Available - device has SMART capability.
SMART support is: Enabled
AAM feature is:   Unavailable
APM feature is:   Disabled
Rd look-ahead is: Enabled
Write cache is:   Enabled
DSN feature is:   Unavailable
ATA Security is:  Disabled, frozen [SEC2]
Wt Cache Reorder: Enabled

=== START OF READ SMART DATA SECTION ===
SMART overall-health self-assessment test result: PASSED

General SMART Values:
Offline data collection status:  (0x85)	Offline data collection activity
					was aborted by an interrupting command from host.
					Auto Offline Data Collection: Enabled.
Self-test execution status:      ( 117)	The previous self-test completed having
					the read element of the test failed.
Total time to complete Offline 
data collection: 		(21217) seconds.
Offline data collection
capabilities: 			 (0x5b) SMART execute Offline immediate.
					Auto Offline data collection on/off support.
					Suspend Offline collection upon new
					command.
					Offline surface scan supported.
					Self-test supported.
					No Conveyance Self-test supported.
					Selective Self-test supported.
SMART capabilities:            (0x0003)	Saves SMART data before entering
					power-saving mode.
					Supports SMART auto save timer.
Error logging capability:        (0x01)	Error logging supported.
					General Purpose Logging supported.
Short self-test routine 
recommended polling time: 	 (   1) minutes.
Extended self-test routine
recommended polling time: 	 ( 354) minutes.
SCT capabilities: 	       (0x003d)	SCT Status supported.
					SCT Error Recovery Control supported.
					SCT Feature Control supported.
					SCT Data Table supported.

SMART Attributes Data Structure revision number: 16
Vendor Specific SMART Attributes with Thresholds:
ID# ATTRIBUTE_NAME          FLAGS    VALUE WORST THRESH FAIL RAW_VALUE
  1 Raw_Read_Error_Rate     PO-R--   100   100   016    -    0
  2 Throughput_Performance  P-S---   140   140   054    -    67
  3 Spin_Up_Time            POS---   130   130   024    -    441 (Average 440)
  4 Start_Stop_Count        -O--C-   100   100   000    -    339
  5 Reallocated_Sector_Ct   PO--CK   100   100   005    -    0
  7 Seek_Error_Rate         PO-R--   100   100   067    -    0
  8 Seek_Time_Performance   P-S---   124   124   020    -    33
  9 Power_On_Hours          -O--C-   095   095   000    -    39724
 10 Spin_Retry_Count        PO--C-   100   100   060    -    0
 12 Power_Cycle_Count       -O--CK   100   100   000    -    327
192 Power-Off_Retract_Count -O--CK   100   100   000    -    497
193 Load_Cycle_Count        -O--C-   100   100   000    -    497
194 Temperature_Celsius     -O----   150   150   000    -    40 (Min/Max 15/55)
196 Reallocated_Event_Count -O--CK   100   100   000    -    5
197 Current_Pending_Sector  -O---K   100   100   000    -    48
198 Offline_Uncorrectable   ---R--   100   100   000    -    0
199 UDMA_CRC_Error_Count    -O-R--   200   200   000    -    2888
                            ||||||_ K auto-keep
                            |||||__ C event count
                            ||||___ R error rate
                            |||____ S speed/performance
                            ||_____ O updated online
                            |______ P prefailure warning

n0mad ★★★
() автор топика
Ответ на: комментарий от ALiEN175

ПРОДОЛЖЕНИЕ

General Purpose Log Directory Version 1
SMART           Log Directory Version 1 [multi-sector log support]
Address    Access  R/W   Size  Description
0x00       GPL,SL  R/O      1  Log Directory
0x01           SL  R/O      1  Summary SMART error log
0x03       GPL     R/O      1  Ext. Comprehensive SMART error log
0x04       GPL     R/O      7  Device Statistics log
0x06           SL  R/O      1  SMART self-test log
0x07       GPL     R/O      1  Extended self-test log
0x08       GPL     R/O      2  Power Conditions log
0x09           SL  R/W      1  Selective self-test log
0x10       GPL     R/O      1  NCQ Command Error log
0x11       GPL     R/O      1  SATA Phy Event Counters log
0x20       GPL     R/O      1  Streaming performance log [OBS-8]
0x21       GPL     R/O      1  Write stream error log
0x22       GPL     R/O      1  Read stream error log
0x80-0x9f  GPL,SL  R/W     16  Host vendor specific log
0xe0       GPL,SL  R/W      1  SCT Command/Status
0xe1       GPL,SL  R/W      1  SCT Data Transfer

SMART Extended Comprehensive Error Log Version: 1 (1 sectors)
Device Error Count: 2982 (device log contains only the most recent 4 errors)
	CR     = Command Register
	FEATR  = Features Register
	COUNT  = Count (was: Sector Count) Register
	LBA_48 = Upper bytes of LBA High/Mid/Low Registers ]  ATA-8
	LH     = LBA High (was: Cylinder High) Register    ]   LBA
	LM     = LBA Mid (was: Cylinder Low) Register      ] Register
	LL     = LBA Low (was: Sector Number) Register     ]
	DV     = Device (was: Device/Head) Register
	DC     = Device Control Register
	ER     = Error register
	ST     = Status register
Powered_Up_Time is measured from power on, and printed as
DDd+hh:mm:SS.sss where DD=days, hh=hours, mm=minutes,
SS=sec, and sss=millisec. It "wraps" after 49.710 days.

Error 2982 [1] occurred at disk power-on lifetime: 39715 hours (1654 days + 19 hours)
  When the command that caused the error occurred, the device was active or idle.

  After command completion occurred, registers were:
  ER -- ST COUNT  LBA_48  LH LM LL DV DC
  -- -- -- == -- == == == -- -- -- -- --
  40 -- 51 00 01 00 00 0e e5 ab 17 0e 00  Error: UNC 1 sectors at LBA = 0x0ee5ab17 = 249932567

  Commands leading to the command that caused the error were:
  CR FEATR COUNT  LBA_48  LH LM LL DV DC  Powered_Up_Time  Command/Feature_Name
  -- == -- == -- == == == -- -- -- -- --  ---------------  --------------------
  25 20 20 00 01 00 00 0e e5 ab 17 e0 00     10:45:56.969  READ DMA EXT
  35 20 20 00 01 00 00 0e e5 ab 16 e0 00     10:45:56.969  WRITE DMA EXT
  25 20 20 00 01 00 00 0e e5 ab 16 e0 00     10:45:56.969  READ DMA EXT
  25 20 20 00 01 00 00 0e e5 ab 17 e0 00     10:45:56.649  READ DMA EXT
  25 20 20 00 01 00 00 0e e5 ab 16 e0 00     10:45:56.649  READ DMA EXT

Error 2981 [0] occurred at disk power-on lifetime: 39715 hours (1654 days + 19 hours)
  When the command that caused the error occurred, the device was active or idle.

  After command completion occurred, registers were:
  ER -- ST COUNT  LBA_48  LH LM LL DV DC
  -- -- -- == -- == == == -- -- -- -- --
  40 -- 51 00 01 00 00 0e e5 ab 17 0e 00  Error: UNC 1 sectors at LBA = 0x0ee5ab17 = 249932567

  Commands leading to the command that caused the error were:
  CR FEATR COUNT  LBA_48  LH LM LL DV DC  Powered_Up_Time  Command/Feature_Name
  -- == -- == -- == == == -- -- -- -- --  ---------------  --------------------
  25 20 20 00 01 00 00 0e e5 ab 17 e0 00     10:45:56.649  READ DMA EXT
  25 20 20 00 01 00 00 0e e5 ab 16 e0 00     10:45:56.649  READ DMA EXT
  35 20 20 00 01 00 00 0e e5 ab 16 e0 00     10:45:56.649  WRITE DMA EXT
  35 20 20 00 01 00 00 0e e5 ab 15 e0 00     10:45:56.649  WRITE DMA EXT
  35 20 20 00 01 00 00 0e e5 ab 16 e0 00     10:45:56.649  WRITE DMA EXT

Error 2980 [3] occurred at disk power-on lifetime: 39715 hours (1654 days + 19 hours)
  When the command that caused the error occurred, the device was active or idle.

  After command completion occurred, registers were:
  ER -- ST COUNT  LBA_48  LH LM LL DV DC
  -- -- -- == -- == == == -- -- -- -- --
  40 -- 51 00 01 00 00 0e e5 ab 16 0e 00  Error: UNC 1 sectors at LBA = 0x0ee5ab16 = 249932566

  Commands leading to the command that caused the error were:
  CR FEATR COUNT  LBA_48  LH LM LL DV DC  Powered_Up_Time  Command/Feature_Name
  -- == -- == -- == == == -- -- -- -- --  ---------------  --------------------
  25 20 20 00 01 00 00 0e e5 ab 16 e0 00     10:45:56.496  READ DMA EXT
  35 20 20 00 01 00 00 0e e5 ab 15 e0 00     10:45:56.496  WRITE DMA EXT
  25 20 20 00 01 00 00 0e e5 ab 15 e0 00     10:45:56.496  READ DMA EXT
  25 20 20 00 01 00 00 0e e5 ab 16 e0 00     10:45:56.176  READ DMA EXT
  25 20 20 00 01 00 00 0e e5 ab 15 e0 00     10:45:56.176  READ DMA EXT

Error 2979 [2] occurred at disk power-on lifetime: 39715 hours (1654 days + 19 hours)
  When the command that caused the error occurred, the device was active or idle.

  After command completion occurred, registers were:
  ER -- ST COUNT  LBA_48  LH LM LL DV DC
  -- -- -- == -- == == == -- -- -- -- --
  40 -- 51 00 01 00 00 0e e5 ab 16 0e 00  Error: UNC 1 sectors at LBA = 0x0ee5ab16 = 249932566

  Commands leading to the command that caused the error were:
  CR FEATR COUNT  LBA_48  LH LM LL DV DC  Powered_Up_Time  Command/Feature_Name
  -- == -- == -- == == == -- -- -- -- --  ---------------  --------------------
  25 20 20 00 01 00 00 0e e5 ab 16 e0 00     10:45:56.176  READ DMA EXT
  25 20 20 00 01 00 00 0e e5 ab 15 e0 00     10:45:56.176  READ DMA EXT
  35 20 20 00 01 00 00 0e e5 ab 15 e0 00     10:45:56.176  WRITE DMA EXT
  35 20 20 00 01 00 00 0e e5 ab 14 e0 00     10:45:56.176  WRITE DMA EXT
  35 20 20 00 01 00 00 0e e5 ab 15 e0 00     10:45:56.175  WRITE DMA EXT

n0mad ★★★
() автор топика
Ответ на: комментарий от ALiEN175

ПРОДОЛЖЕНИЕ

SMART Extended Self-test Log Version: 1 (1 sectors)
Num  Test_Description    Status                  Remaining  LifeTime(hours)  LBA_of_first_error
# 1  Extended offline    Completed: read failure       50%     39721         2750853704
# 2  Extended offline    Completed without error       00%     31577         -

SMART Selective self-test log data structure revision number 1
 SPAN  MIN_LBA  MAX_LBA  CURRENT_TEST_STATUS
    1        0        0  Not_testing
    2        0        0  Not_testing
    3        0        0  Not_testing
    4        0        0  Not_testing
    5        0        0  Not_testing
Selective self-test flags (0x0):
  After scanning selected spans, do NOT read-scan remainder of disk.
If Selective self-test is pending on power-up, resume after 0 minute delay.

SCT Status Version:                  3
SCT Version (vendor specific):       256 (0x0100)
Device State:                        Active (0)
Current Temperature:                    40 Celsius
Power Cycle Min/Max Temperature:     36/40 Celsius
Lifetime    Min/Max Temperature:     15/55 Celsius
Under/Over Temperature Limit Count:   0/0

SCT Temperature History Version:     2
Temperature Sampling Period:         1 minute
Temperature Logging Interval:        1 minute
Min/Max recommended Temperature:      0/60 Celsius
Min/Max Temperature Limit:           -40/70 Celsius
Temperature History Size (Index):    128 (61)

Index    Estimated Time   Temperature Celsius
  62    2025-04-21 16:59    38  *******************
 ...    ..( 25 skipped).    ..  *******************
  88    2025-04-21 17:25    38  *******************
  89    2025-04-21 17:26    39  ********************
 ...    ..( 19 skipped).    ..  ********************
 109    2025-04-21 17:46    39  ********************
 110    2025-04-21 17:47    40  *********************
 111    2025-04-21 17:48    39  ********************
 112    2025-04-21 17:49    39  ********************
 113    2025-04-21 17:50    39  ********************
 114    2025-04-21 17:51    40  *********************
 115    2025-04-21 17:52    40  *********************
 116    2025-04-21 17:53    40  *********************
 117    2025-04-21 17:54    39  ********************
 118    2025-04-21 17:55    40  *********************
 119    2025-04-21 17:56    39  ********************
 ...    ..(  3 skipped).    ..  ********************
 123    2025-04-21 18:00    39  ********************
 124    2025-04-21 18:01    40  *********************
 ...    ..(  2 skipped).    ..  *********************
 127    2025-04-21 18:04    40  *********************
   0    2025-04-21 18:05    39  ********************
   1    2025-04-21 18:06    40  *********************
 ...    ..(  6 skipped).    ..  *********************
   8    2025-04-21 18:13    40  *********************
   9    2025-04-21 18:14    39  ********************
  10    2025-04-21 18:15    40  *********************
 ...    ..( 16 skipped).    ..  *********************
  27    2025-04-21 18:32    40  *********************
  28    2025-04-21 18:33    39  ********************
  29    2025-04-21 18:34    40  *********************
 ...    ..(  2 skipped).    ..  *********************
  32    2025-04-21 18:37    40  *********************
  33    2025-04-21 18:38    39  ********************
  34    2025-04-21 18:39    40  *********************
  35    2025-04-21 18:40    39  ********************
  36    2025-04-21 18:41    40  *********************
 ...    ..(  2 skipped).    ..  *********************
  39    2025-04-21 18:44    40  *********************
  40    2025-04-21 18:45    39  ********************
  41    2025-04-21 18:46    39  ********************
  42    2025-04-21 18:47    40  *********************
  43    2025-04-21 18:48    40  *********************
  44    2025-04-21 18:49    39  ********************
  45    2025-04-21 18:50    39  ********************
  46    2025-04-21 18:51    39  ********************
  47    2025-04-21 18:52    40  *********************
  48    2025-04-21 18:53    39  ********************
  49    2025-04-21 18:54    40  *********************
 ...    ..( 11 skipped).    ..  *********************
  61    2025-04-21 19:06    40  *********************

SCT Error Recovery Control:
           Read: Disabled
          Write: Disabled

n0mad ★★★
() автор топика
Ответ на: комментарий от ALiEN175

ЗАВЕРШЕНИЕ

Device Statistics (GP Log 0x04)
Page  Offset Size        Value Flags Description
0x01  =====  =               =  ===  == General Statistics (rev 1) ==
0x01  0x008  4             327  ---  Lifetime Power-On Resets
0x01  0x010  4           39724  ---  Power-on Hours
0x01  0x018  6    113226492017  ---  Logical Sectors Written
0x01  0x020  6      1174973436  ---  Number of Write Commands
0x01  0x028  6    458169679661  ---  Logical Sectors Read
0x01  0x030  6      2687905514  ---  Number of Read Commands
0x03  =====  =               =  ===  == Rotating Media Statistics (rev 1) ==
0x03  0x008  4           39718  ---  Spindle Motor Power-on Hours
0x03  0x010  4           39718  ---  Head Flying Hours
0x03  0x018  4             497  ---  Head Load Events
0x03  0x020  4               0  ---  Number of Reallocated Logical Sectors
0x03  0x028  4              84  ---  Read Recovery Attempts
0x03  0x030  4               9  ---  Number of Mechanical Start Failures
0x04  =====  =               =  ===  == General Errors Statistics (rev 1) ==
0x04  0x008  4              94  ---  Number of Reported Uncorrectable Errors
0x04  0x010  4              13  ---  Resets Between Cmd Acceptance and Completion
0x05  =====  =               =  ===  == Temperature Statistics (rev 1) ==
0x05  0x008  1              40  ---  Current Temperature
0x05  0x010  1              38  N--  Average Short Term Temperature
0x05  0x018  1              35  N--  Average Long Term Temperature
0x05  0x020  1              55  ---  Highest Temperature
0x05  0x028  1              15  ---  Lowest Temperature
0x05  0x030  1              51  N--  Highest Average Short Term Temperature
0x05  0x038  1              25  N--  Lowest Average Short Term Temperature
0x05  0x040  1              45  N--  Highest Average Long Term Temperature
0x05  0x048  1              25  N--  Lowest Average Long Term Temperature
0x05  0x050  4               0  ---  Time in Over-Temperature
0x05  0x058  1              60  ---  Specified Maximum Operating Temperature
0x05  0x060  4               0  ---  Time in Under-Temperature
0x05  0x068  1               0  ---  Specified Minimum Operating Temperature
0x06  =====  =               =  ===  == Transport Statistics (rev 1) ==
0x06  0x008  4             856  ---  Number of Hardware Resets
0x06  0x010  4             538  ---  Number of ASR Events
0x06  0x018  4            2888  ---  Number of Interface CRC Errors
                                |||_ C monitored condition met
                                ||__ D supports DSN
                                |___ N normalized value

Pending Defects log (GP Log 0x0c) not supported

SATA Phy Event Counters (GP Log 0x11)
ID      Size     Value  Description
0x0001  2            0  Command failed due to ICRC error
0x0002  2            0  R_ERR response for data FIS
0x0003  2            0  R_ERR response for device-to-host data FIS
0x0004  2            0  R_ERR response for host-to-device data FIS
0x0005  2            0  R_ERR response for non-data FIS
0x0006  2            0  R_ERR response for device-to-host non-data FIS
0x0007  2            0  R_ERR response for host-to-device non-data FIS
0x0009  2           20  Transition from drive PhyRdy to drive PhyNRdy
0x000a  2           20  Device-to-host register FISes sent due to a COMRESET
0x000b  2            0  CRC errors within host-to-device FIS
0x000d  2            0  Non-CRC errors within host-to-device FIS

n0mad ★★★
() автор топика
Ответ на: комментарий от n0mad

Ну непосредственно битых секторов нет. Пять попыток переназначения, 48 секторов под подозрением. Что вы «ремапить» собрались?

И подсказка. Вместо копипасты портянок c миллионом строк на форум - use force, Luke!

COMMAND_WITH_LOOONG_OUTPUT | curl -F 'file=@-' 0x0.st
ALiEN175
()
Последнее исправление: ALiEN175 (всего исправлений: 1)

Побуду КО. Если винт дороже данных на нем, то можно играться с ним как угодно. В противном случае действительно випомойку.

einhander ★★★★★
()
Ответ на: комментарий от n0mad

5 Reallocated_Sector_Ct PO–CK 100 100 005 - 0

196 Reallocated_Event_Count -O–CK 100 100 000 - 5

https://www.ixbt.com/storage/hdd-smart-testing.shtml#n23

199 UDMA_CRC_Error_Count -O-R– 200 200 000 - 2888

Обычно огромное количество 199 означает кабель в помойку. Но, учитывая:

# 1 Extended offline Completed: read failure 50% 39721 2750853704

скорее всего, уходит в помойку сам диск. Ну и только 2 smart теста за всю жизнь диска, на котором невероятно важные данные - это тоже весело.

Dimez ★★★★★
()
Последнее исправление: Dimez (всего исправлений: 2)
Ответ на: комментарий от Dimez

5 Reallocated_Sector_Ct PO–CK 100 100 005 - 0
196 Reallocated_Event_Count -O–CK 100 100 000 - 5

https://www.ixbt.com/storage/hdd-smart-testing.shtml#n23

199 UDMA_CRC_Error_Count -O-R– 200 200 000 - 2888
Обычно огромное количество 199 означает кабель в помойку. Но, учитывая:

Кстати если спец. Эта цифра за всю жизнь диска или с последнего включения? Вообще в СМАРТ есть значения с последнего включения? Или все копятся за всю жизнь диска? Возможно и попадались некачественные кабели, так же он пережил и долгое стояние, и переезд в другой город.

# 1 Extended offline Completed: read failure 50% 39721 2750853704

Вот как раз интересно, за этими 50% на которых он остановился - можно протестить? А с Read failure мы ещё разберемся. Может данные со временем «протухли»? Хотя... (zpool stastus -v между делом добавил ещё один файл).

T3T1S  creation              Пн апр 29  4:12 2024  -

Этот том создал всего год назад и время записи данных не старее.
Вообще, как всё прочитаю - запущу badblocks -n и посмотрю что диск скажет после его исполнения.

скорее всего, уходит в помойку сам диск.

Ну пока пусть будет для барахла качаемого из интернета.

Ну и только 2 smart теста за всю жизнь диска, на котором невероятно важные данные - это тоже весело.

Да, мне стыдно, но радует что у меня не всё так плохо как у Шумахера. Он на лыжах голову убил, я на параплане...

n0mad ★★★
() автор топика
Ответ на: комментарий от n0mad

Я тебе по-человечески сочувствую, но если диск начал сыпаться, то он будет сыпаться дальше. И если тебе важны данные на нем, то лучшее решение - это заменить диск. Если все же используешь битый диск, то не храни на нем данные, которые не можешь потом восстановить.

PRN
()
Ответ на: комментарий от n0mad

Вот как раз интересно, за этими 50% на которых он остановился - можно протестить

У смарта есть т.е. selective тесты, где указываешь диапазон блоков. Но оно того не стоит. Контроллер диска не может что-то делать со сбойным или подозрительным сектором, пока в секторе лежат данные пользователя. Можно хоть сто миллионов раз читать из битого сектора и отлетать по ошибке, но диск ничего не сделает, кроме как, может быть но не обязательно, занесёт сектор в pending. Потому что всегда есть надежда на, например, dd_rescue или лабораторию восстановления данных, и вообще данные пользователя священны (очень здравый инженерный подход).

Чтобы диск мог вынести сектору приговор нужно, чтобы хост отдал приказ на запись, тем самым объявив данные в секторе неважными. Только тогда диск сможет проверить сектор и переназначить или оправдать. Точного алгоритма я не знаю.

Поэтому самотестирование диска бесполезно в этом смысле. Оно может только подтвердить, что всё хорошо.

PS ещё совет - следи, чтобы во время длительных тяжёлых операций диск не перегревался. Старый диск это может добить. Крышку с корпуса пека сними, вентилятор на корзину дисков поставь, разнеси разные диски подальше друг от друга.

legolegs ★★★★★
()
Ответ на: комментарий от n0mad

Почтенный гуру, уже сказал по делу: «badblocks», она может и сканить и писать адресно.

Нет, badblocks не умеет ни читать ни писать адресно, и -w и -n будут просто перезаписывать весь диск. Для затирания только повреждённых секторов тебе придётся вызывать dd с указанием смещения вручную.

anonymous
()
Ответ на: комментарий от ALiEN175

Ремапом уже лет дцать занимается только сам контроллер диска.

Тут дело в том, что контроллер жутко тупит когда начинают появляться «сбойные» сектора, а система встаёт колом в read-only как только чтение сектора профейлилось. Приходится руками читать сектора, если не читается, записывать нулями и ВНЕЗАПНО сектор вдруг стал снова читаем. Падажите, так ведь сектор усё, почему запись нулями его исправила? Вот так прослужил мой WD-шный винт на 500 гб всего 3 года пока не началась эта параша с контроллером (то есть прослужил ровно них*ра). Reallocated sector count до сих пор равен нулю, даже smart тесты после ручного исправления секторов проходит, храню на нём всякий ненужный шлак, который некуда положить. Вам не кажется, что это какое-то запланированное устаревание? Вот у меня с 2004-года где-то был винт на 80Гб (ещё по IDE подключался), там этой шизы с бытыми секторами никогда не было, если сектор битый, то контроллер его запомоивал и всё. Кстати диск до сих пор работает.

Ну ладно хрен там, если винт на 500Гб, а 3Тб, 6Тб+?. Ценники на них посмотрите.

Все эти «сектора Шрёдингера» ещё хуже чем просто битые сектора.

Skullnet ★★★★☆
()
Последнее исправление: Skullnet (всего исправлений: 1)
Ответ на: комментарий от Skullnet

Выше я уже объяснил. Некоторым ФС абсолютно фиолетово, что у них сам накопитель не в лучшей кондиции. Ну ошибка и ошибка. Типа ничего страшного. Другие ФС очень критично относятся к состоянию HDD и при первой же неоднозначной ситуации всеми способами пытаются сигнализировать о неисправности. Судя по темам ТС - у него как раз второй вариант. Что он там хочет сделать с диском - мне непонятно.

ALiEN175
()
Ответ на: комментарий от Skullnet

Ценники на них посмотрите.

А что ценники? Хочется задорого всё яйца в одной корзинке хранить - пожалуйста. Покупайте хоть 20 Тб.

Для важной инфы я предпочитаю холодное хранение в ящике стола, ну или хотя-бы первый рейд. А при любом подозрении на неисправность харда - помечаю что он «ненадёжный» и не храню на нём никакой критической инфы. Сдох - и сдох. Без сожалений, какой он красивый и дорогой был при при покупке. И не вбрасывая ерунду в интернете по типу «как заремапить дохлый диск».

ALiEN175
()
Последнее исправление: ALiEN175 (всего исправлений: 3)
Ответ на: комментарий от anonymous

Почтенный гуру, уже сказал по делу: «badblocks», она может и сканить и писать адресно.

Нет, badblocks не умеет ни читать ни писать адресно, и -w и -n будут просто перезаписывать весь диск. Для затирания только повреждённых секторов тебе придётся вызывать dd с указанием смещения вручную.

man badblocks

NAME
       badblocks - search a device for bad blocks

SYNOPSIS
   badblocks  [  -svwnfBX  ]  [ -b block_size ] [ -c blocks_at_once ] [ -d
   read_delay_factor ] [ -e max_bad_blocks ] [ -i input_file ] [  -o  out‐
   put_file  ] [ -p num_passes ] [ -t test_pattern ] device [ last_block ]
   [ first_block ]

last_block и first_block - зачем?

n0mad ★★★
() автор топика
Ответ на: комментарий от ALiEN175

Для важной инфы я предпочитаю холодное хранение в ящике стола,

Холодное хранение на чём?

ну или хотя-бы первый рейд.

Первый рейд это про отказоустойчивость, а не надёжность.

А при любом подозрении на неисправность харда - помечаю что он «ненадёжный» и не храню на нём никакой критической инфы.

Бэкапы уже отменили? Хотя да, критическую инфу на рейде, а рейд битые винты не любит.

Сдох - и сдох. Без сожалений, какой он красивый и дорогой был при при покупке.

Если есть средства - запросто, а если их нет?

И не вбрасывая ерунду в интернете по типу «как заремапить дохлый диск».

т.е. сидеть так...

Хотя если технология есть, то почему не попробовать?

n0mad ★★★
() автор топика
Последнее исправление: n0mad (всего исправлений: 2)
Ответ на: комментарий от n0mad

Холодное хранение на чём?

Холодное хранение

рейд это про отказоустойчивость, а не надёжность.

А чем отличается отказоустойчивость от надёжности? Семантические свойства устойчивых словосочетаний в студию.

Бэкапы уже отменили?

А вот их никто не отменял.

ALiEN175
()
Ответ на: комментарий от Skullnet

ВНЕЗАПНО сектор вдруг стал снова читаем. Падажите, так ведь сектор усё, почему запись нулями его исправила?

Все сектора на диске хранятся вместе с контрольной суммой. Диск при считывании её проверяет. Сектора на самом деле не могут не читаться, физически они всегда читаются (если шпиндель крутится и головка ездит), просто иногда контрольная сумма не сходится. Условно, один бит физически имеет намагниченность 0.49 попугаев и, с учётом помех и погрешностей +-0.1 иногда читается как логическая 1, а иногда как 0. В этом смысл того, что диск сам читает сектор несколько раз, если первый раз контрольная сумма не сошлась. Мы это ощущаем как задержку.

Так вот, почему один или несколько бит имеют намагниченость, которая не читается однозначно? Это либо дефект поверхности, либо пылинка, либо прошло много времени и намагничивание ослабло, либо при записи был какой-то сбой и головка не промагнитила нормально.

Короче, проверь питание - БП, разъёмы.

anonymous
()
Ответ на: комментарий от anonymous

Интересно, а где раньше были все эти пылынки, контакты и т.д. Что сейчас у дисков «секторное расстройство». Это не единичный случай, у меня многократно, у топикстартера. Это конечно весело, что если у тебя на 6Тб винте появилось пара сбойных секторов - его нужно сразу на помойку нести.

Skullnet ★★★★☆
()
Ответ на: комментарий от Skullnet

Интересно, а где раньше были все эти пылынки, контакты и т.д

Раньше плотность записи была намного меньше, неужели это не очевидно? Раньше диски вообще в открытом виде вполне себе работали без проблем.

Dimez ★★★★★
()
Ответ на: комментарий от Dimez

Раньше плотность записи была намного меньше, неужели это не очевидно?

Как это относится к глюкам контроллера и неспособности нормально определять битые сектора?

Skullnet ★★★★☆
()
Последнее исправление: Skullnet (всего исправлений: 1)
Ответ на: комментарий от Skullnet

Как это относится к глюкам контроллера и неспособности нормально определять битые сектора?

Ты рассуждать вообще не умеешь? Плотность возросла => сложность определения возросла, соседние домены влияют, а на черепице вообще хз как справляются.

Dimez ★★★★★
()
Ответ на: комментарий от Dimez

Ты рассуждать вообще не умеешь? Плотность возросла => сложность определения возросла, соседние домены влияют, а на черепице вообще хз как справляются.

А мне вот интересно, кто нибудь знает?
Есть ли в винтах - сервисные программы, перезаписывающие сектора с данными?
А то вон и в флешках, и ссдшках, кто то утверждает что есть и поэтому флешки/ссдшки - нельзя долго хранить без питания.
Может и винты нельзя долго хранить без питания?

n0mad ★★★
() автор топика
Ответ на: комментарий от n0mad

деградация магнитного домена на порядки медленнее, чем деградация электрического заряда.
если hdd хранить эдак очень много сотен лет - он тоже «разрядится» и информация сотрется.

даже в черепице размер домена весьма большой.

pfg ★★★★★
()
Ответ на: комментарий от Dimez

Плотность возросла => сложность определения возросла

Слабо верится. Скорее всего у современных дисков в прошивках крайне хреновая коррекция ошибок, что они начинают тупить уже как только появляются первые нечитаемые сектора. Это как с лампочками, может работать почти вечно, но это не выгодно, поэтому установим ограничение в сроке работы. В результате мы получаем диски со сроком службы около 3-х лет.

Skullnet ★★★★☆
()
Последнее исправление: Skullnet (всего исправлений: 1)
Ответ на: комментарий от YAR

WHDD?

Добрался наконец, смог собрать эту утилиту.
Запустил, сначала красиво, но не смог получить ни чего кроме гуёвого просмотра SMART. Для чего то более - нужно подбирать драйвера, дистрибутивы. Даже обработки ошибок нет, их надо искать где то в системных журналах.
В общем SMART увидел, а попытка хотя бы Read-Test, задаёт все вопросы и выкидывает в основное меню. Хотя собралось без ошибок и запускалось от рута.

n0mad ★★★
() автор топика
Ответ на: комментарий от n0mad

А может кто подскажет «заклинания» или ссылку на хауту - позволящее просто рекурсивно читать всё содержимое fs и вести журнал с ошибками чтения?

Даю подсказку - https://t.me/kun4sun_bot

theurs ★★
()
Ответ на: комментарий от theurs

А может кто подскажет «заклинания» или ссылку на хауту - позволящее просто рекурсивно читать всё содержимое fs и вести журнал с ошибками чтения?

Даю подсказку - https://t.me/kun4sun_bot

Чуть выше уже писал, есть простое решение, которое просто вылетело из головы.

find ./ -type f -exec cat '{}' \; |pv|dd of=/dev/null

Оно дало:
cat: './:DL/_Win/USBFlash/141228x2-MultibootUSB/MULTIBOOT_USB_FLASH_ 8Gb-16Gb_NT
FS_v.9.0_2014/FLASH-V.9.0/2SFX-FLASH-16Gb+/SOURCE8/WIN8x86/install.esd': Ошибка
ввода/вывода
cat: './:DL/0C0py/_MultiSystemCDDVD/ISO/LiveCD&USB/Multiboot-Flash/Multiboot Fla
sh Filth Edition 2013 + UEFI 7.0 Final 32 Гб/Multiboot Flash Filth Edition 2013.
GHO.BAD': Ошибка ввода/вывода

4516222353+540921 records in
4516459826+1 records out
2312427431266 bytes (2,3 TB, 2,1 TiB) copied, 36283,4 s, 63,7 MB/s

Где видны файлы с ошибками. Пока оно читало, конечно пришел к другому синтаксису но пока не проверял:
find ./ -type f -exec cat '{}' \; >/dev/null 2>Error.log

Проверю после того как вычленю все плохие сектора и пройдусь по ним badblocks.
К сожалению это всё отнимает много времени, но появится опыт.

n0mad ★★★
() автор топика
Последнее исправление: n0mad (всего исправлений: 2)
Ответ на: комментарий от anonymous

Спасибо, но я пока не владею математикой по вычислению и затиранию найденных секторов.

Не надо ничего вычислять. badblocks -o journal.txt ... найдет сектора, badblocks -w ... их затрет.

Но увы, я не нашел как перезаписать только то что выпало в бэды. Это же тьма времени. Сначала часов 14 искать бэды, сохранять в файл, а потом заново полностью прогонять badblocks -n, уже с чтением/записью - странно что нельзя по списку :(

Думаю для начала нужен просто инструмент перезаписывающий диск. Тупо - все сектора, прочитал-записал.

badblocks -n

Спасибо, и ведь знал же - но забыл :(

n0mad ★★★
() автор топика
Ответ на: комментарий от anonymous

Спасибо, но я пока не владею математикой по вычислению и затиранию найденных секторов.

Не надо ничего вычислять. badblocks -o journal.txt ... найдет сектора, badblocks -w ... их затрет.

Спасибо Отработал. Получил файл, не стал много прогонять. Взял пару блоков, скажем:

1375426852
1375426853

Думаю для начала нужен просто инструмент перезаписывающий диск. Тупо - все сектора, прочитал-записал.

badblocks -n

Исполнил: badblocks -f -n -o 852-sdd-badblocks.log /dev/sdd 1375426853 1375426852
Затем:badblocks -o 852-sdd-badblocks.log /dev/sdd 1375426853 1375426852
он показал что эти блоки так и остались нечитаемыми.
Хорошо, попробовал:
hdparm --repair-sector 1375426852 --yes-i-know-what-i-am-doing /dev/sdd
hdparm --repair-sector 1375426853 --yes-i-know-what-i-am-doing /dev/sdd
Чтение показало что ошибка осталась.
Меня мучают сомнения в правильности позиционирования, особенно для hdparm. Или всё похоже на правильное?

В общем пока ни badblocks ни hdparm - эти 2 сектора не заремапили.
Сейчас спать, проснусь посмотрю что конструктивное сказали, пока результаты неутешительные.
badblocks.log из 28 строк.

Подскажите ещё, как этот файл из построчного списка бэдов - можно скормить hdparm-у? В качестве параметров для repair-sector.

n0mad ★★★
() автор топика
Ответ на: комментарий от n0mad

Вроде, слышал, что есть такие заводские сервисные метки на поверхности блинов. Ну, типа, чёткой разметки на дорожки как у cd, dvd, blue-ray у hdd нет, т.е. магнитная поверхность просто ровная. Ну, вот как раз заводские метки и создают структуру кольцевых «дорожек». И по этим меткам и ищутся нужное кольцо и сектор.

Ну, и типа метки по сути ничуть не сильнее «промагничены», чем обычные секторы с данными. Они точно так же могут «размагнититься», «посыпаться», «поцарапаться» или даже «затереться» сбрендившим перегревшимся контроллером.

Вот после такой потери сервисной метки контроллер и начинает «щёлках коромыслом» с головкой в многочисленных попыках найти нужную локацию и не может.

Пользователь же восстановить заводскую разметку никак не может.

Пруфов сейчас не найду…

anonymous
()
Ответ на: комментарий от legolegs

-n означает, что badblocks сначала прочитает блок. А он не может, это же нечитаемый блок. Тебе надо попрощаться с файлом и затереть его кусок через -w

Спасибо, о таком поведении я не подумал.
Поменял для первой серии битых секторов -n на -w и всё! Сектора читаются!

Всего 4 серии:


1375426852
1375426853
1375426854
1375426855
1375426856
1375426857
1375426858
1375426859
1375426860
1375426861
1375426862
1375426863

1676240792
1676240793
1676240794
1676240795
1676240796
1676240797
1676240798
1676240799

1676243640
1676243641
1676243642
1676243643

1676243652
1676243653
1676243654
1676243655

n0mad ★★★
() автор топика
Последнее исправление: n0mad (всего исправлений: 3)
Ответ на: комментарий от legolegs

badblocks -f -n

-n означает, что badblocks сначала прочитает блок. А он не может, это же нечитаемый блок. Тебе надо попрощаться с файлом и затереть его кусок через -w

СПАСИБО, о ГУРУ!
В общем SMART:

197 Current_Pending_Sector  0x0022   100   100   000    Old_age   Always       -
       48

с помощью badblocks получил список плохих блоков.
Они были 4 диапазонами
Подставил эти диапазоны в badblocks -w и всё!
197 Current_Pending_Sector  0x0022   100   100   000    Old_age   Always       -
       0


Сейчас запущу -t long, как пройдёт - отчитаюсь.

n0mad ★★★
() автор топика
Ответ на: комментарий от legolegs

А вообще, вся эта ситуация наводит на мысли - раз в пол года прогонять badblocks -n для всех винтов, обновить намагниченность.

А вообще, у «посыпавшегося» винта:

  9 Power_On_Hours          0x0012   095   095   000    Old_age   Always       -
       39745

А это 4.5 года онлайна.

И по USB3, подключен Самсунг 1Т, с 82780 часами, а это 9.4 года онлайн.

n0mad ★★★
() автор топика
Последнее исправление: n0mad (всего исправлений: 4)
Ответ на: комментарий от anonymous

значит это можно починить низкоуровневым форматированием

Уржошься! Это починилось - записью нулей в сбойные сектора.

n0mad ★★★
() автор топика
Последнее исправление: n0mad (всего исправлений: 1)

Обновил стартовый пост, мануалом о том как решил проблему. Пройдёт финальное тестирование и отмечу тему как решенную!
Хотя ещё прогоню badblocks -n для 3Т Тошибы, посмотрю и зафиксирую время и результаты.

n0mad ★★★
() автор топика
Последнее исправление: n0mad (всего исправлений: 1)
Ответ на: комментарий от n0mad

Сейчас запущу -t long, как пройдёт - отчитаюсь.

Нагуглил «вкусняшку»:

# watch "smartctl -a /dev/sdd|grep progress -i -A 1"

Показывает:
Every 2,0s: smartctl -a /dev/sdd|grep progres...  zer0: Wed Apr 23 14:18:35 2025

Self-test execution status:      ( 246) Self-test routine in progress...
                                        60% of test remaining.

А тем временем прошло 3 часа...

n0mad ★★★
() автор топика
Последнее исправление: n0mad (всего исправлений: 1)
Ответ на: комментарий от n0mad

Выспался. Результаты -t long:

SMART Self-test log structure revision number 1
Num  Test_Description    Status                  Remaining  LifeTime(hours)  LBA_of_first_error
# 1  Extended offline    Completed: read failure       40%     39752         3352487288

Проверяем:
badblocks -o 07-sdd-badblocks.log /dev/sdd 3352488289 3352487288

Но! Факир был пьян! SMART и BADBLOCKS видимо оперируют разными размерами сектора!
# badblocks -o 07-sdd-badblocks.log /dev/sdd 3352488289 3352487288
badblocks: Недопустимый аргумент during seek
badblocks: Недопустимый аргумент during seek
badblocks: Недопустимый аргумент during seek
badblocks: Недопустимый аргумент during seek
badblocks: Недопустимый аргумент during seek
badblocks: Недопустимый аргумент during seek
badblocks: Недопустимый аргумент during seek
badblocks: Недопустимый аргумент during seek
badblocks: Недопустимый аргумент during seek
badblocks: Недопустимый аргумент during seek
badblocks: Недопустимый аргумент during seek
badblocks: Недопустимый аргумент during seek
badblocks: Недопустимый аргумент during seek
badblocks: Недопустимый аргумент during seek
badblocks: Недопустимый аргумент during seek
badblocks: Недопустимый аргумент during seek

Придётся повторить badblocks и посмотреть его видение!

n0mad ★★★
() автор топика
Ответ на: комментарий от n0mad

Но! Факир был пьян! SMART и BADBLOCKS видимо оперируют разными размерами сектора!

Так и есть. Размер сектора ЖД – 512 или 4096, размер блока у badblocks – 1024 байт.

Придётся повторить badblocks и посмотреть его видение!

Или поменять размер блока у badblocks: -b 512. И заодно добавить опций для прогресса (на журнал не повлияют): -s -v, а также поискать сбойные сектора рядом:

$ s=3352487288
$ badblocks -s -v -b 512 -o 07-sdd-badblocks.log /dev/sdd $(( $s + 10000 )) $(( $s - 10000 ))

Размер сектора и увеличенное количество блоков -b 4096 -c 65536 могут ускорить проверку всего диска.

Непосредственно перед затиранием желательно запустить badblocks без -w.

anonymous
()