Festplatte hängt beim Schreiben, friert das halbe System ein

L

linuxfan

Gast
An meinem Odroid-C2, auf dem Armbian läuft, hängt eine externe Festplatte (WD Red 3TB). Mir ist aufgefallen, dass es immer wieder unerklärliche Freezes gibt, wenn die Platte fast voll ist und geschrieben wird. Es äußert sich dann so, dass die Schreibbefehle hängen und kein Ende mehr finden. Ein simples "touch DATEI" ist nicht mehr möglich. Außerdem kommt es im Zuge dessen dazu, dass man sich nicht mehr per SSH auf das System einloggen kann. Nach erfolgreichem Passworteingeben hängt der SSH irgendwie - da passiert gar nichts mehr, nicht mal eine Fehlermeldung. Im VNC, wo ich schon eingeloggt bin, kann ich noch hantieren - nur nicht auf die Platte schreiben.

Mit der Platte selber scheint eigentlich alles in Ordnung zu sein. Ich muss das System dann halt ausmachen und anschließend fsck drüberlaufen lassen, dann wird das Dateisystem repariert und alles scheint wieder zu laufen. Aber wenn ich wieder ein paar GB schreibe, dann hängt es wieder.

Wo liegt der Fehler? Macht der Odroid schlapp? Hat der Chipsatz oder was auch immer Probleme mit nahezu vollen 3TB-Platten? Ich finde das unerklärlich.

Auf der Platte sind nur Daten, das System ist auf der SD-Karte.

Ich hatte das Problem immer wieder mal alle paar Monate, und immer war die Platte dann ziemlich voll. Wenn ich viel löschte, ging es wieder.
 
Kann einige Gründe haben:
  • Platte geht in Energiesparmodus, Odroid hängt, bis die wieder da ist
  • Die Platte hat Probleme -> smartmon/smartctl -> SMART-Status auslesen
  • Dein Dateisystem hat Probleme -> fsck
  • Der Controller/das Kabel hat Probleme

mal im Syslog nachgeschaut? dmesg? messages?
 
Ich sehe per top, fsck läuft nach dem zwangsweisen Neu-Booten gerade von selber durch. Würde es was bringen, es danach selber noch mal anzustoßen? Ich habe es vorhin erst gemacht per "fsck -y /dev/sda1" dabei wurde auch was korrigiert und alles ging wieder. Aber nach einigem Schreiben (paar GB) hing es wieder.

Ansonsten kenne ich mich wenig aus. Smartmon werde ich mich mal wieder einlesen, hatte das irgendwann auch mal gemacht, sah alles gut aus.

Von Syslog & Co. habe ich kaum Ahnung, habe das bisher so gut wie nie gebraucht. Kann man da irgendwas standardmäßig mal eben eingeben um auf die Schnelle Infos zu bekommen?

Edit, so hier mal smartctl:
Code:
root@odroidc2:~# smartctl -H /dev/sda
smartctl 6.6 2016-05-31 r4324 [aarch64-linux-4.19.69-meson64] (local build)
Copyright (C) 2002-16, Bruce Allen, Christian Franke, www.smartmontools.org

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

Jetzt hat er die Platte auch wieder gemountet, ich sehe sie ist zu 85% voll. Der Fehler kam immer nur dann, wenn die Platte sehr voll war, so wie jetzt auch wieder.

Ich kann normalerweise stundenlang schreiben, ohne dass die Platte sich abschalten würde.
 
Zuletzt bearbeitet von einem Moderator:
linuxfan schrieb:
SMART overall-health self-assessment test result: PASSED

Der Satz ist nett aber leider wenig Aussagekräftig.

smartctl -t long /dev/sda

Dann wird deine Platte einmal komplett getestet.
 
Code:
smartctl -t long /dev/sda
smartctl 6.6 2016-05-31 r4324 [aarch64-linux-4.19.69-meson64] (local build)
Copyright (C) 2002-16, Bruce Allen, Christian Franke, www.smartmontools.org

=== START OF OFFLINE IMMEDIATE AND SELF-TEST SECTION ===
Sending command: "Execute SMART Extended self-test routine immediately in off-line mode".
Drive command "Execute SMART Extended self-test routine immediately in off-line mode" successful.
Testing has begun.
Please wait 397 minutes for test to complete.
Test will complete after Fri Jan 31 04:57:39 2020

Use smartctl -X to abort test.
root@odroidc2:~#
Habe das jetzt eingegebn, es soll angeblich 400 Minuten dauern. Wird das Ergebnis in ein Log geschrieben? Ich bin nämlich gleich wieder am Prompt gelandet.
 
Lese doch erstmal mit smartctl -a /dev/sda die Attribute und die Logs aus.
 
Code:
smartctl -a /dev/sda
smartctl 6.6 2016-05-31 r4324 [aarch64-linux-4.19.69-meson64] (local build)
Copyright (C) 2002-16, Bruce Allen, Christian Franke, www.smartmontools.org

=== START OF INFORMATION SECTION ===
Model Family:     Western Digital Red
Device Model:     WDC WD30EFRX-68EUZN0
Serial Number:    -
LU WWN Device Id: -
Firmware Version: 82.00A82
User Capacity:    3,000,592,982,016 bytes [3.00 TB]
Sector Sizes:     512 bytes logical, 4096 bytes physical
Rotation Rate:    5400 rpm
Device is:        In smartctl database [for details use: -P show]
ATA Version is:   ACS-2 (minor revision not indicated)
SATA Version is:  SATA 3.0, 6.0 Gb/s (current: 6.0 Gb/s)
Local Time is:    Thu Jan 30 22:28:07 2020 CET
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:  (0x00) Offline data collection activity
                                        was never started.
                                        Auto Offline Data Collection: Disabled.
Self-test execution status:      ( 121) The previous self-test completed having
                                        the read element of the test failed.
Total time to complete Offline
data collection:                (39540) seconds.
Offline data collection
capabilities:                    (0x7b) SMART execute Offline immediate.
                                        Auto Offline data collection on/off support.
                                        Suspend Offline collection upon new
                                        command.
                                        Offline surface scan supported.
                                        Self-test supported.
                                        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:        (   2) minutes.
Extended self-test routine
recommended polling time:        ( 397) minutes.
Conveyance self-test routine
recommended polling time:        (   5) minutes.
SCT capabilities:              (0x703d) 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     0x002f   200   200   051    Pre-fail  Always       -       55
  3 Spin_Up_Time            0x0027   179   171   021    Pre-fail  Always       -       6041
  4 Start_Stop_Count        0x0032   096   096   000    Old_age   Always       -       4152
  5 Reallocated_Sector_Ct   0x0033   200   200   140    Pre-fail  Always       -       0
  7 Seek_Error_Rate         0x002e   100   253   000    Old_age   Always       -       0
  9 Power_On_Hours          0x0032   073   073   000    Old_age   Always       -       20400
 10 Spin_Retry_Count        0x0032   100   100   000    Old_age   Always       -       0
 11 Calibration_Retry_Count 0x0032   100   100   000    Old_age   Always       -       0
 12 Power_Cycle_Count       0x0032   099   099   000    Old_age   Always       -       1327
192 Power-Off_Retract_Count 0x0032   200   200   000    Old_age   Always       -       166
193 Load_Cycle_Count        0x0032   197   197   000    Old_age   Always       -       11364
194 Temperature_Celsius     0x0022   114   109   000    Old_age   Always       -       36
196 Reallocated_Event_Count 0x0032   200   200   000    Old_age   Always       -       0
197 Current_Pending_Sector  0x0032   200   200   000    Old_age   Always       -       6
198 Offline_Uncorrectable   0x0030   100   253   000    Old_age   Offline      -       0
199 UDMA_CRC_Error_Count    0x0032   200   200   000    Old_age   Always       -       0
200 Multi_Zone_Error_Rate   0x0008   100   253   000    Old_age   Offline      -       0

SMART Error Log Version: 1
No Errors Logged

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       90%     20400         1206806144
# 2  Short offline       Interrupted (host reset)      90%      1609         -
# 3  Short offline       Interrupted (host reset)      80%      1512         -
# 4  Short offline       Completed without error       00%      1012         -
# 5  Short offline       Interrupted (host reset)      80%         0         -
# 6  Short offline       Interrupted (host reset)      80%         0         -

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.

root@odroidc2:~#
 
linuxfan schrieb:
197 Current_Pending_Sector 0x0032 200 200 000 Old_age Always - 6
Die Platte hat schwebende Sektoren und Schwebende Sektoren sind einfach nur Sektoren deren Daten nicht mehr zur ECC passen die hinter jedem Sektor steht und die mit deren Hilfe auch nicht mehr korrigiert werden können. Da die korrekten Daten nicht mehr feststellbar sind, gibt die Platte statt falscher Daten einen Lesefehler als Antwort wenn man versucht diese schwebenden Sektoren zu lesen. Das kann auch anderen Gründe als defekte Oberflächen haben, z.B. einen Stromausfall während eines Schreibvorgang der dazu führt, dass eben nicht die ganze Daten plus der neuen ECC geschrieben wurden oder wegen eines Stoßes oder Vibrationen ist der Kopf beim Schreiben aus der Spur gekommen und hat Daten auf der Nachbarspur überschrieben. Auch arbeiten HDDs nicht 100%ig und die Hersteller geben die Fehlerhäufigkeit auch in Form der UBER an, wobei eine UBER von 1:10^14 bedeutet, dass je 10^14 gelesener Bits was etwa 12TB gelesener Daten entspricht, ein Lesefehler und damit schwebender Sektor im Rahmen der Erwartungen liegt.

Die Controller merken sich die schwebenden Sektoren und prüfen die Daten nach dem erneuten Schreiben auf diese Sektoren, dann verschwinden diese einfach oder werden eben durch Reservesektoren ersetzt.

Diese hat der Selbsttest auch gefunden:
linuxfan schrieb:
# 1 Extended offline Completed: read failure 90% 20400 1206806144
Das die Platte und damit der Rechner hängen wenn versucht wird diese zu lesen, ist normal. Die Red hat TLER, da ist der Timeout einstellbar wie lange sie versucht solche Sektoren durch wiederholte Versuche doch noch zu lesen, der Default sollte 7s betragen, aber wenn die SW oder das OS es selbst auch noch mehrfach versuchen, kann es natürlich auch ein Vielfaches davon werden.
 
  • Gefällt mir
Reaktionen: linuxfan
@Holt Lesen habe ich nun noch probiert, aber das ging absolut nicht mehr. Jedesmal minutenlange Hänger, deren Ende nicht abzusehen war, die auch andere Systemdienste wie SSH-Login blockieren und einen Neustart erforderten. Ich habe die zuletzt geschrieben Daten nun gelöscht und nochmals geschrieben. Also du scheinst völlig recht zu haben mit deiner Einschätzung. Denn bisher gab es keine Hänger mehr. Ist es anzuraten, sich vorsichtshalber eine neue Platte zu besorgen? Können solche Fehler auch rein durch ein vom Lese- und Schreibfluss "überfordertem" angeschlossenen Gerät (Odroid-C2) verursacht werden, oder kann man sagen, dass es auf jeden Fall an der Platte selber liegt (also physikalisch verursacht)? Es scheinen wohl mehrere Dateien und somit wohl auch Sektoren betroffen gewesen zu sein, aber da ich einfach alles zuletzt Geschriebene gelöscht habe (mehrere GB), lässt sich das jetzt nicht mehr ganz nachvollziehen.
 
linuxfan schrieb:
Ist es anzuraten, sich vorsichtshalber eine neue Platte zu besorgen?
Gibt es denn jetzt wiederzugewiesene Sektoren? Wenn die schwebende Sektoren nach dem Überschreiben einfach nur verschwinden, dann war die Platte nicht beschädigt, dann war vermutlich Stöße oder Vibrationen verantwortlich und haben bei einem Schreibvorgang dafür gesorgt, dass die Köpfe Daten auf der Nachbarspur überschrieben haben. Die Red sollte als NAS Platte zwar einen Schutz vor Vibrationen haben, aber eben nur einen einfachen, die Red sind ja nur für bis zu 8 Platten pro Gehäuse zugelassen, die Red Pro immerhin für bis zu 16. Es gibt auch dort unterschiedlich aufwendige und damit teure Technologien. Manchmal kann ein Bass in der Nähe schon reichen um solche Probleme zu machen.
linuxfan schrieb:
Können solche Fehler auch rein durch ein vom Lese- und Schreibfluss "überfordertem" angeschlossenen Gerät (Odroid-C2) verursacht werden
Nein, dies kann nicht sein. Wenn der Datenstrom zu groß ist, dann wird die Antwortzeit zu hoch, aber es gibt davon keine schwebenden Sektoren.
 
  • Gefällt mir
Reaktionen: linuxfan
Zurück
Oben