URE beim mdadm reshape/grow

[WilliTheSmith]

Hi,
ich habe meinem Storage am Wochenende einen HBA (Fujitsu CP400i, IT-Firmware geflasht) spendiert. Nach ein paar Tests kamen noch zwei Platten dazu und das Raid 6 wurde von 6 auf 8 Platten vergrößert. Gestern wurde ich dann im Monitoring noch während des reshape/grow von einem tollen Fehler begrüßt: "Uncorrectable errors: 2". Ein md-check lief am 1.5. noch problemlos durch.

Das mdraid hat sich davon nicht sonderlich beeindrucken lassen, Auszug aus Kernel-Log:

[Di Mai 17 11:43:16 2022] mpt3sas_cm0: log_info(0x31080000): originator(PL), code(0x08), sub_code(0x0000)
[Di Mai 17 11:43:16 2022] mpt3sas_cm0: log_info(0x31080000): originator(PL), code(0x08), sub_code(0x0000)
..... (Wiederholung 5x)
[Di Mai 17 11:43:16 2022] mpt3sas_cm0: log_info(0x31080000): originator(PL), code(0x08), sub_code(0x0000)
[Di Mai 17 11:43:16 2022] sd 0:0:0:0: [sda] tag#5171 FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE cmd_age=3s
[Di Mai 17 11:43:16 2022] sd 0:0:0:0: [sda] tag#5171 Sense Key : Medium Error [current]
[Di Mai 17 11:43:16 2022] sd 0:0:0:0: [sda] tag#5171 Add. Sense: Unrecovered read error
[Di Mai 17 11:43:16 2022] sd 0:0:0:0: [sda] tag#5171 CDB: Read(10) 28 00 d4 24 41 80 00 00 80 00
[Di Mai 17 11:43:16 2022] blk_update_request: critical medium error, dev sda, sector 28473167168 op 0x0:(READ) flags 0x4000 phys_seg 88 prio class 0
[Di Mai 17 11:43:19 2022] mpt3sas_cm0: log_info(0x31080000): originator(PL), code(0x08), sub_code(0x0000)
..... (Wiederholung ~30x)
[Di Mai 17 11:43:19 2022] mpt3sas_cm0: log_info(0x31080000): originator(PL), code(0x08), sub_code(0x0000)
[Di Mai 17 11:43:19 2022] sd 0:0:0:0: [sda] tag#5168 FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE cmd_age=3s
[Di Mai 17 11:43:19 2022] sd 0:0:0:0: [sda] tag#5168 Sense Key : Medium Error [current]
[Di Mai 17 11:43:19 2022] sd 0:0:0:0: [sda] tag#5168 Add. Sense: Unrecovered read error
[Di Mai 17 11:43:19 2022] sd 0:0:0:0: [sda] tag#5168 CDB: Read(10) 28 00 d4 24 41 a8 00 00 01 00
[Di Mai 17 11:43:19 2022] blk_update_request: critical medium error, dev sda, sector 28473167168 op 0x0:(READ) flags 0x4000 phys_seg 1 prio class 0
[Di Mai 17 11:43:20 2022] md/raid:md127: read error corrected (8 sectors at 28473165120 on sda1)

Betroffene Platte ist übrigens eine Ironwolf Pro 16TB.

Mein Verständnis von diesem Fall ist:
1. md hat für den Reshape-Vorgang zwei Sektoren angefordert, auf die die HDD (sda) keine Daten liefern konnte, da die interne Checksum nicht zu den ausgelesenen Daten gepasst haben. Klassischer URE.
2. Controller/HBA, System und Software spielen hierbei keine Rolle und sind unschuldig.
3. md hat durch seine Redundanzen den Sektor korrigiert, daher ist es auch nach wie vor im clean state.

Ist dies soweit korrekt?

Hier noch ein Auszug aus smartctl:

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   078   064   044    Pre-fail  Always       -       8144215
  3 Spin_Up_Time            0x0003   089   087   000    Pre-fail  Always       -       0
  4 Start_Stop_Count        0x0032   087   087   020    Old_age   Always       -       13651
  5 Reallocated_Sector_Ct   0x0033   100   100   010    Pre-fail  Always       -       0
  7 Seek_Error_Rate         0x000f   084   060   045    Pre-fail  Always       -       261807400
  9 Power_On_Hours          0x0032   083   083   000    Old_age   Always       -       15624
 10 Spin_Retry_Count        0x0013   100   100   097    Pre-fail  Always       -       0
 12 Power_Cycle_Count       0x0032   100   100   020    Old_age   Always       -       65
 18 Head_Health             0x000b   100   100   050    Pre-fail  Always       -       0
187 Reported_Uncorrect      0x0032   098   098   000    Old_age   Always       -       2
188 Command_Timeout         0x0032   100   099   000    Old_age   Always       -       8590065666
190 Airflow_Temperature_Cel 0x0022   064   044   040    Old_age   Always       -       36 (Min/Max 24/41)
192 Power-Off_Retract_Count 0x0032   100   100   000    Old_age   Always       -       8
193 Load_Cycle_Count        0x0032   082   082   000    Old_age   Always       -       36979
194 Temperature_Celsius     0x0022   036   056   000    Old_age   Always       -       36 (0 21 0 0 0)
197 Current_Pending_Sector  0x0012   100   100   000    Old_age   Always       -       0
198 Offline_Uncorrectable   0x0010   100   100   000    Old_age   Offline      -       0
199 UDMA_CRC_Error_Count    0x003e   200   200   000    Old_age   Always       -       0
200 Pressure_Limit          0x0023   100   100   001    Pre-fail  Always       -       0
240 Head_Flying_Hours       0x0000   100   253   000    Old_age   Offline      -       4491h+15m+27.125s
241 Total_LBAs_Written      0x0000   100   253   000    Old_age   Offline      -       27959026715
242 Total_LBAs_Read         0x0000   100   253   000    Old_age   Offline      -       36151239967

SMART Error Log Version: 1
ATA Error Count: 2
        CR = Command Register [HEX]
        FR = Features Register [HEX]
        SC = Sector Count Register [HEX]
        SN = Sector Number Register [HEX]
        CL = Cylinder Low Register [HEX]
        CH = Cylinder High Register [HEX]
        DH = Device/Head Register [HEX]
        DC = Device Command Register [HEX]
        ER = Error register [HEX]
        ST = Status register [HEX]
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 2 occurred at disk power-on lifetime: 15601 hours (650 days + 1 hours)
  When the command that caused the error occurred, the device was active or idle.

  After command completion occurred, registers were:
  ER ST SC SN CL CH DH
  -- -- -- -- -- -- --
  40 51 00 ff ff ff 0f  Error: UNC at LBA = 0x0fffffff = 268435455

  Commands leading to the command that caused the error were:
  CR FR SC SN CL CH DH DC   Powered_Up_Time  Command/Feature_Name
  -- -- -- -- -- -- -- --  ----------------  --------------------
  60 00 01 ff ff ff 4f 00   1d+11:26:26.748  READ FPDMA QUEUED
  60 00 01 ff ff ff 4f 00   1d+11:26:26.748  READ FPDMA QUEUED
  60 00 01 ff ff ff 4f 00   1d+11:26:26.748  READ FPDMA QUEUED
  60 00 01 ff ff ff 4f 00   1d+11:26:26.748  READ FPDMA QUEUED
  60 00 01 ff ff ff 4f 00   1d+11:26:26.748  READ FPDMA QUEUED

Error 1 occurred at disk power-on lifetime: 15601 hours (650 days + 1 hours)
  When the command that caused the error occurred, the device was active or idle.

  After command completion occurred, registers were:
  ER ST SC SN CL CH DH
  -- -- -- -- -- -- --
  40 51 00 ff ff ff 0f  Error: UNC at LBA = 0x0fffffff = 268435455

  Commands leading to the command that caused the error were:
  CR FR SC SN CL CH DH DC   Powered_Up_Time  Command/Feature_Name
  -- -- -- -- -- -- -- --  ----------------  --------------------
  60 00 0e ff ff ff 4f 00   1d+11:26:23.102  READ FPDMA QUEUED
  61 00 65 ff ff ff 4f 00   1d+11:26:23.102  WRITE FPDMA QUEUED
  61 00 80 ff ff ff 4f 00   1d+11:26:23.102  WRITE FPDMA QUEUED
  60 00 80 ff ff ff 4f 00   1d+11:26:23.102  READ FPDMA QUEUED
  60 00 80 ff ff ff 4f 00   1d+11:26:23.099  READ FPDMA QUEUED

Auffällig hier ist:
Reported_Uncorrect = 2, klar, deshalb bin ich ja drauf aufmerksam geworden.
Aber: Pending sowie reallocated Sektor-Count 0, betroffene Sektoren scheint also i.O. und wurden einfach mit den korrekten Daten neu beschrieben? Wie kritisch ist das? Mir fehlt da leider die Erfahrung. In der Firma wird einfach ausgetauscht, wenn der Controller oder das Monitoring Fehler zeigt.

Zur Zeit läuft auf der Platte ein Long Smart-Test, der benötigt etwa 24h.
Anschließend ist noch ein Data-Scrub geplant, um final definitiv sicherzustellen, dass die Daten i.O. sind.


Abschließend:
Ist das bereits ein Fall für ein RMA? Wenn nein, ab wann wäre es das? Ohne Redundanz oder Backup hätte man afaik jetzt an den Sektoren einen Datenverlust erlitten. Sorgen um meine Daten mache ich mir zur Zeit jedoch nicht, vor allem da zwei Paritätsplatten genutzt werden und ein Backup vorhanden ist.

Wäre cool, wenn sich hier wer mit Ahnung in dem Bereich zu äußern könnte, damit ich auch weiterhin gut schlafen kann.

 

[kieleich]

mdadm korrigiert Lesefehler von sich aus - natürlich nur wenn Redundanz vor handen

Erst wenn die Korrektur (Schreiben) auch ein Fehler ist, wird die Platte, aus dem Array geworfen

Oder, im Fall von Bad Block Log, als Fehler haft markiert das kannst du, mit mdadm --examine oder --examine-badblocks, prüfen für alle Platten im Array

Dann läuft die Platte zwar weiter, im Array, aber keine Redundanz, für diesen Sektor - also Murks

leider ist es üblich daß Festplatten ihre Fehler verheimlichen also alle Zähler wieder auf 0 gehen

ob das ein totaler Ausfall ist kann man diskutieren aber das Vertrauen ist auf jeden Fall hinüber

 

[0x7c9aa894]

Bei einem Raid sollen sich HDDs anders verhalten als bei einer einzelnen Platte.
1 HDD + Fehler => Fehler bleibt bis User etwas tut

Beim Raid, will man, daß das Raid das löst, deshalb haben die meisten Platten HDDs eine Einstellung dafür.

SCT Error Recovery Control:
           Read:     70 (7.0 seconds)
          Write:     70 (7.0 seconds)

https://en.wikipedia.org/wiki/Error_recovery_control

Ist das bereits ein Fall für ein RMA?

Noch nicht, aber ich würde mir schon mal eine neue HDD bestellen ...

Ich mache dann meist einen Smart long test, da tauchen, dann meist viele weitere Fehler auf.

https://www.backblaze.com/blog/hard-drive-smart-stats/

 

[WilliTheSmith]

Danke für eure Antworten.

https://en.wikipedia.org/wiki/Error_recovery_control

Oh, das muss ich mir mal genauer ansehen. Man ist ja lernwillig.

Noch nicht, aber ich würde mir schon mal eine neue HDD bestellen ...

Ich mache dann meist einen Smart long test, da tauchen, dann meist viele weitere Fehler auf.

Long Smart-Test läuft bereits, wie oben geschrieben. Bin gespannt, ob da was raus kommt. Beim Reshape wurde die Platte ja auch komplett gelesen und es gab "nur" zwei Fehler.

 

[Inzersdorfer]

Die beiden reported uncorrectables sind Lesevorgänge die auch innerhalb der vorgesehenen Wiederholungen nicht fehlerfrei durchgeführt werden konnten, damit korrespondieren die 2 command timeouts. Da es aber keine Lesefehler gibt (erste 4 Stellen des hexadezimalen Rohwertes) muß der Lesevorgang schlußendlich doch noch erfolgreich abgeschloßen worden sein. Den Inhalt des betroffenen Sektor auslagern und Selbigen mittels hdparm Nullen.