• Diese Seite verwendet Cookies. Indem du diese Website weiterhin nutzt, erklärst du dich mit der Verwendung von Cookies einverstanden. Erfahre mehr

Sterbende Platte

pom

Well-Known Member
Themenstarter #1
Hallo,

mir ist jetzt 2 mal innerhalb von einigen Tagen der Server "stehengeblieben". Untenstehendes gibt smartctl raus.
Die Betriebsstunden sind hoch.

Deuten diese Fehler auf Plattenprobleme hin oder liegt es vielleicht doch eher
an meinem neuen Motherboard / SATA Verkabelung?

Danke und Gruß,
Peter


smartctl -a /dev/ada0
smartctl 7.1 2019-12-30 r5022 [FreeBSD 12.1-RELEASE-p9 amd64] (local build)
Copyright (C) 2002-19, Bruce Allen, Christian Franke, www.smartmontools.org

=== START OF INFORMATION SECTION ===
Model Family: Hitachi Deskstar 5K3000
Device Model: Hitachi HDS5C3020ALA632
Serial Number: ML0220F30MJ0WD
LU WWN Device Id: 5 000cca 369c8df38
Firmware Version: ML6OA580
User Capacity: 2,000,398,934,016 bytes [2.00 TB]
Sector Size: 512 bytes logical/physical
Rotation Rate: 5940 rpm
Form Factor: 3.5 inches
Device is: In smartctl database [for details use: -P show]
ATA Version is: ATA8-ACS T13/1699-D revision 4
SATA Version is: SATA 2.6, 6.0 Gb/s (current: 6.0 Gb/s)
Local Time is: Thu Sep 10 17:09:26 2020 CEST
SMART support is: Available - device has SMART capability.
SMART support is: Enabled

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

General SMART Values:
Offline data collection status: (0x80)Offline data collection activity
was never started.
Auto Offline Data Collection: Enabled.
Self-test execution status: ( 0)The previous self-test routine completed
without error or no self-test has ever
been run.
Total time to complete Offline
data collection: (23306) 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: ( 389) 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 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 134 134 054 Pre-fail Offline - 100
3 Spin_Up_Time 0x0007 137 137 024 Pre-fail Always - 400 (Average 398)
4 Start_Stop_Count 0x0012 100 100 000 Old_age Always - 285
5 Reallocated_Sector_Ct 0x0033 100 100 005 Pre-fail Always - 0
7 Seek_Error_Rate 0x000b 100 100 067 Pre-fail Always - 0
8 Seek_Time_Performance 0x0005 144 144 020 Pre-fail Offline - 30
9 Power_On_Hours 0x0012 093 093 000 Old_age Always - 51446
10 Spin_Retry_Count 0x0013 100 100 060 Pre-fail Always - 0
12 Power_Cycle_Count 0x0032 100 100 000 Old_age Always - 283
192 Power-Off_Retract_Count 0x0032 100 100 000 Old_age Always - 368
193 Load_Cycle_Count 0x0012 100 100 000 Old_age Always - 368
194 Temperature_Celsius 0x0002 181 181 000 Old_age Always - 33 (Min/Max 16/46)
196 Reallocated_Event_Count 0x0032 100 100 000 Old_age Always - 0
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 - 4

SMART Error Log Version: 1
ATA Error Count: 4
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 4 occurred at disk power-on lifetime: 51323 hours (2138 days + 11 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
-- -- -- -- -- -- --
84 51 02 cd 93 e6 0b Error: ICRC, ABRT at LBA = 0x0be693cd = 199660493

Commands leading to the command that caused the error were:
CR FR SC SN CL CH DH DC Powered_Up_Time Command/Feature_Name
-- -- -- -- -- -- -- -- ---------------- --------------------
61 02 02 cd 93 e6 4b ff 22:03:23.077 WRITE FPDMA QUEUED
61 02 68 cd 93 e6 40 00 22:03:23.076 WRITE FPDMA QUEUED
ef 02 00 00 00 00 40 00 22:03:23.076 SET FEATURES [Enable write cache]
ef aa 00 00 00 00 40 00 22:03:23.076 SET FEATURES [Enable read look-ahead]
c6 00 10 00 00 00 40 00 22:03:23.076 SET MULTIPLE MODE

Error 3 occurred at disk power-on lifetime: 51323 hours (2138 days + 11 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
-- -- -- -- -- -- --
84 51 02 e5 89 e6 0b Error: ICRC, ABRT at LBA = 0x0be689e5 = 199657957

Commands leading to the command that caused the error were:
CR FR SC SN CL CH DH DC Powered_Up_Time Command/Feature_Name
-- -- -- -- -- -- -- -- ---------------- --------------------
61 10 02 e5 89 e6 4b ff 22:03:22.968 WRITE FPDMA QUEUED
61 10 28 10 83 e0 40 00 22:03:22.967 WRITE FPDMA QUEUED
61 02 20 e5 89 e6 40 00 22:03:22.938 WRITE FPDMA QUEUED
60 10 18 10 03 00 40 00 22:03:22.938 READ FPDMA QUEUED
60 10 10 10 85 e0 40 00 22:03:22.938 READ FPDMA QUEUED

Error 2 occurred at disk power-on lifetime: 51323 hours (2138 days + 11 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
-- -- -- -- -- -- --
84 51 02 b3 59 03 0f Error: ICRC, ABRT at LBA = 0x0f0359b3 = 251877811

Commands leading to the command that caused the error were:
CR FR SC SN CL CH DH DC Powered_Up_Time Command/Feature_Name
-- -- -- -- -- -- -- -- ---------------- --------------------
61 02 02 b3 59 03 4f ff 22:03:22.830 WRITE FPDMA QUEUED
61 02 c8 b3 59 03 40 00 22:03:22.829 WRITE FPDMA QUEUED
61 1a c0 6d c8 61 40 00 22:03:22.825 WRITE FPDMA QUEUED
61 01 b8 72 50 f8 40 00 22:03:22.825 WRITE FPDMA QUEUED
61 19 b0 0d 92 22 40 00 22:03:22.825 WRITE FPDMA QUEUED

Error 1 occurred at disk power-on lifetime: 51301 hours (2137 days + 13 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
-- -- -- -- -- -- --
84 51 4c b2 71 00 03 Error: ICRC, ABRT at LBA = 0x030071b2 = 50360754

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 20 f0 62 03 40 00 1d+03:58:00.515 READ FPDMA QUEUED
61 4c 18 b2 71 00 40 00 1d+03:58:00.515 WRITE FPDMA QUEUED
61 4e 10 b8 6e 00 40 00 1d+03:58:00.515 WRITE FPDMA QUEUED
61 26 08 97 3e 00 40 00 1d+03:58:00.515 WRITE FPDMA QUEUED
61 0d 00 2e 30 00 40 00 1d+03:58:00.515 WRITE FPDMA QUEUED

SMART Self-test log structure revision number 1
Num Test_Description Status Remaining LifeTime(hours) LBA_of_first_error
# 1 Extended offline Completed without error 00% 13337 -
# 2 Short offline Completed without error 00% 11720 -

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.
 

Nonpareille

Well-Known Member
#2
Ohne Gewähr: ich wurde als erstes die Verkabelung prüfen. Weil die Fehler (Zeile 199 in der in der Smart-Auflistung) können sowohl von Board/Verkabelung als auch von der Plattenelektronik kommen. Die entscheidenden Zeilen 196/197/198 haben aber den Wert 0.
Unabhängig davon solltest Du aber eine Ersatzplatte bereithalten, denn diese ist ja nun fast 6 Jahre gelaufen, kommt also langsam in den Bereich, wo die Badewannenkurve wieder ansteigt, sprich auch mechanische Schäden wieder wahrscheinlich werden.
 

mr44er

moderater Moderator
Mitarbeiter
#3
Trotz der Laufzeit hat die Platte perfekte Werte. Fürs Verständnis: die Platte hängt direkt am Board, also kein weiterer Controller/HBA?

199 UDMA_CRC_Error_Count 0x000a 200 200 000 Old_age Always - 4 <- Das sind genau die extra gelisteten vier Fehler. Entweder stimmt wirklich was mit den Kabel/Anschlüssen nicht, aber ich vermute eher was mit dem power management. Schau im BIOS mal, ob es powerzeug / APM/ AAM / spindown bei SATA zu deaktivieren gibt.

Auch schadet ein smartctl -t long /dev/ada0 Durchlauf nicht. (Achtung: dauert ewig!)
 

pom

Well-Known Member
Themenstarter #5
Fürs Verständnis: die Platte hängt direkt am Board, also kein weiterer Controller/HBA?
Die Platten hängen an einem C242 Chipsatz und sind über einen passiven Hot-Plug Käfig angebunden.

aber ich vermute eher was mit dem power management
Das war der richtige Hinweis + die Feststellung, dass die Platten, wenn ich sie im Betrieb ziehe/stecke nicht mehr erkannt werden.
Ich habe verschiedene Settings probiert um den Stromverbrauch zu senken.

Mit ist einfallen, dass ich für die Platten etwas in loader.conf aus einer Webseite reinkopiert habe :-(

hint.ahcich.0.pm_level=5
...
-> driver initiates SLUMBER PM state transition 125ms after port becomes idle

Das habe ich jetzt rausgenommen. Hot-Plug läuft jetzt wieder.

Ich beobachte ob es auch das Problem mit den Plattenfehlern löst.

Gruß,
Peter
 

mr44er

moderater Moderator
Mitarbeiter
#6
Jep, wie ich es im anderen Thread schon andeutete: Es gibt viel auf der Strecke, was reingrätschen könnte. Verhält sich der Käfig wirklich passiv oder tut er nicht doch nonkonform eine Einstellung setzen oder killen? Stellt er sein eigenes hotplug bereit oder reicht er brav durch? Wie reagiert was auf div. power settings? Evtl. geht nur eine bestimmte Kombination uswusf.
Solche Dinge. ;)
Aber ich denke, du bist damit auf dem richtigen Weg.
 

pom

Well-Known Member
Themenstarter #7
Ist noch nicht vorrüber

Ich habe folgende Einträge im messages File gefunden:

Sep 5 13:48:11 xxx kernel: pid 35349 (devd), jid 0, uid 0: exited on signal 10 (core dumped)
Sep 5 13:48:15 xxx kernel: (ada0:ahcich0:0:0:0): WRITE_FPDMA_QUEUED. ACB: 61 00 90 d5 20 40 59 00 00 01 00 00
Sep 5 13:48:15 xxx kernel: (ada0:ahcich0:0:0:0): CAM status: CCB request was invalid
Sep 5 13:48:15 xxx kernel: (ada0:ahcich0:0:0:0): Error 22, Unretryable error
Sep 5 13:48:15 xxx kernel: (ada0:ahcich0:0:0:0): WRITE_FPDMA_QUEUED. ACB: 61 00 c5 9a 23 40 55 00 00 01 00 00
Sep 5 13:48:15 xxx kernel: (ada0:ahcich0:0:0:0): CAM status: CCB request was invalid


Sagt das jemand was? Kann es mit dem Core dump davor zusammenhängen?
 

mr44er

moderater Moderator
Mitarbeiter
#8
Evtl. findest du in den Threads was, womit du weiterkommst:

https://www.bsdforen.de/threads/geom_eli-crypto-read-request-failed-error-22.34405/
https://www.bsdforen.de/threads/sas...000vn0004-2gs11l-seagate-ironwolf-10tb.34546/

Fahre das System mal ohne Käfig und vergewissere dich, dass im BIOS sämtliches Stromsparzeug bei SATA aus ist. Es kann auch erstmal helfen, die jeweiligen Ports im BIOS auf SATA300 zu forcieren.
Wiederhole die Tests dann nochmal so granular wie möglich und nimm einen Satz mit anderen Kabeln.
Sitzen die Stromstecker an den Platten / am Käfig knackig und fest?
 

pom

Well-Known Member
Themenstarter #9
Ich habe jetzt 2 Hitachi Platten ausgebaut und gegen WD-Red getauscht.
Bisher läuft alles stabil - :cool:

camcontrol devlist
<WDC WD20EFRX-68EUZN0 82.00A82> at scbus0 target 0 lun 0 (ada0,pass0)
<WDC WD20EFRX-68AX9N0 80.00A80> at scbus1 target 0 lun 0 (ada1,pass1)
<Hitachi HDS5C3020ALA632 ML6OA580> at scbus2 target 0 lun 0 (ada2,pass2)


Nach dem Resilver sieht der Pool jetzt so aus:

Frage: wie bekomme ich den Fehler bzgl. <metadata>:<0x17> behoben?
Was sind das für Daten? Von ZFS selbst?


Gruß,
Peter


pool: zroot
state: ONLINE
status: One or more devices has experienced an error resulting in data
corruption. Applications may be affected.
action: Restore the file in question if possible. Otherwise restore the
entire pool from backup.
see: http://illumos.org/msg/ZFS-8000-8A
scan: resilvered 2.40T in 0 days 10:19:58 with 3 errors on Tue Sep 15 23:25:40 2020
config:


NAME STATE READ WRITE CKSUM
zroot ONLINE 0 0 3
mirror-0 ONLINE 0 0 6
ada2p3 ONLINE 0 0 6
ada1p3 ONLINE 0 0 6 block size: 512B configured, 4096B native
ada0p3 ONLINE 0 0 6 block size: 512B configured, 4096B native


errors: Permanent errors have been detected in the following files:

<metadata>:<0x17>
 

mr44er

moderater Moderator
Mitarbeiter
#10
512B configured, 4096B native <- Das ist suboptimal. Die WDs sind 512e, also lügen 4k nach außen, intern benutzen sie aber 512er Sektoren und dein Pool wurde mit ashift=9 erstellt.
Du hast damit Verschnitt hinsichtlich Speicherplatz und Geschwindigkeit.

Auch hast du CKSUM-Fehler auf allen Partitionen. Ich vermute ada2 hat ne andere Kapazität, wenn auch nur minimal.
 

pom

Well-Known Member
Themenstarter #11
>Sektoren und dein Pool wurde mit ashift=9 erstellt.
Ja, wollte aber nicht auch noch die Baustelle aufmachen

Eine Idee was <metadata>:<0x17> ist?
 

Yamagi

Possessed With Psi Powers
Mitarbeiter
#13
Das heißt, dass ein Block Metadaten zerstört wurde und ZFS ihn bisher nicht reparieren konnte. Das normale vorgehen in solchen Fällen ist den Pool erst einmal als sauber zu markieren:
Code:
% zpool clear zroot
Anschließend wird er fehlerfrei sein, aber man muss auf jeden Fall einen Scrub machen. Andernfalls kann man nicht sicher sein, dass nicht doch Daten zerstört sind, was dann früher oder später wieder zu Checksum-Fehlern führen wird:
Code:
% zpool scrub zroot
Tauchen nach dem Durchlaufen des Scrub wieder Fehler auf, ist der Pool kaputt. Dann kann man nur noch die noch lesbaren Daten per rsync oder so runterkopieren und ihn neu erstellen.
 

mr44er

moderater Moderator
Mitarbeiter
#15
Du hast hoffentlich ein externes Backup?

Ich würde zunächst den Pool mit den alten Platten wieder herstellen und mich um das timeout-Problem kümmern. Natürlich gehts aber auch andersrum: Pool mit den neuen Platten und ashift=12 (ist mittlerweile standard) neu erstellen, Daten aus Backup drauf und währenddessen auf timeouts achten und das dann danach in Angriff nehmen, sofern es natürlich nochmal passiert.