DIY NAS: SoftwareRaid + ext4: Dateisystem zickt

[alex0801]

Hallo zusammen,

ich betreibe eine Debian Linux Kiste, mitunter als NAS. Hierfür stecken zwei Seagate Barracuda 4TB (ja, SMR, ich weiß, CMR wäre besser...) in einem mdadm raid1, ext4 formatiert und freigegeben via SMB und NFS.

Das ganze läuft seit rund 15 Jahren (früher noch mit ext3) mit immer wieder Hardware-Upgrades (beginnend bei 2x80GB, mittlerweile bei 2x4TB) eigentlich ohne Probleme. Hatte wirklich nie Probleme. Okay, mal eine verreckte IBM Platte vor etlichen Jahren. Aber war nie ein Problem. Platte getauscht, Raid wieder gesynct, fertig.

Seit einigen Wochen ärgert mich das System aber durchgehend:

Das RAID hatte eine Platte aus dem Verbund wegen eines Fehler entfernt. Ganz verstanden wieso das passiert ist habe ich nicht. Ich hab die Platte mit smartctl etc. getestet, auch im long-test. Keine Fehler. Also Platte erstmal wieder in den RAID Verbund aufgenommen, gesynct, fertig. Läuft wieder.... unter Beobachtung...

Mittlerweile habe ich aber mindestens ein Verzeichnis im Dateisystem des RAIDs das sich nicht löschen lässt. Fehlermeldung:

Code: Alles auswählen

rm: das Entfernen von 'zm/events/16/2021-09-16/85178/00059-capture.jpg' ist nicht möglich: Die Struktur muss bereinigt werden

Da liegen tausende Files im "zm"-Verzeichnis. Und die Platten machen beim löschversuch etwas "seltsame Geräusche". Hatte in den vergangenen >20 Jahren immer mal wieder ne defekte Platte. Aber so hat noch keine geklungen.

Riecht für mich nach einem Fehler den ich mit e2fsck beheben kann... Pustekuchen. Das findet zwar was, und scheint das auch zu beheben, ändert aber nix an der Tatsache dass ich es mit besagter Fehlermeldung nicht löschen kann.

Gut, dachte ich, mach ich ein Komplett-Backup des 4TB RAID1 auf eine baugleiche weitere 4TB Platte, formatiere das RAUD und schiebe alles zurück. Also rsync angestoßen... Aber auch nach über 10h waren die belegten knapp 2TB noch nicht fertig kopiert. Nicht mal Ansatzweise.

dmesg sagt während dessen primär folgendes:

Code: Alles auswählen

[1183591.219402] EXT4-fs error (device md127): ext4_lookup:1706: inode #158597652: comm e4defrag: iget: bad extra_isize 28338 (inode size 256)
[1183611.609795] EXT4-fs error (device md127): ext4_lookup:1706: inode #158602992: comm rm: iget: bad extra_isize 28338 (inode size 256)
[1183611.675527] EXT4-fs error (device md127): ext4_lookup:1706: inode #158602986: comm rm: iget: bad extra_isize 28338 (inode size 256)
[1183611.700775] EXT4-fs error (device md127): ext4_lookup:1706: inode #158602888: comm rm: iget: bad extra_isize 28338 (inode size 256)
[1183611.735658] EXT4-fs error (device md127): ext4_lookup:1706: inode #158602894: comm rm: iget: bad extra_isize 28338 (inode size 256)
[1183611.774888] EXT4-fs error (device md127): ext4_lookup:1706: inode #158602983: comm rm: iget: bad extra_isize 9234 (inode size 256)
[1183611.800263] EXT4-fs error (device md127): ext4_lookup:1706: inode #158602956: comm rm: iget: bad extra_isize 28338 (inode size 256)
[1183611.833437] EXT4-fs error (device md127): ext4_lookup:1706: inode #158603004: comm rm: iget: bad extra_isize 28338 (inode size 256)
[1183611.874344] EXT4-fs error (device md127): ext4_lookup:1706: inode #158602927: comm rm: iget: bad extra_isize 9234 (inode size 256)

Hmm, also Dateisystem doch noch irgendwie kaputt?

Was ich nicht verstehe:

Wenn smartctl für beide Platten im RAID Verbund keine Fehler im long-test findet, und e2fsck erstmal alle Fehler behebt: Wie kann es dann noch Fehler geben? Und was ist die Ursache?

Jetzt werden viele "Backup hilft" schreien....
Ja, das ist so ne Sache. Wie viele Backups eines 4TB Systems, von dem etwas über 2TB belegt sind passen auf eine 4TB Backup-Platte?
Ich hab auch nicht die Ressourcen um mehrere Backups abzulegen. D.h. eines muss erstmal reichen.

Nun zurück zum Problem: Wenn doch hinter dem ext4 Dateisystem ein RAID1 steckt und beide Platten keinen smartctl erkennbaren Defekt haben: Sollte sich da das Dateisystem nicht reparieren lassen?

Was ist die Ursache für die Fehler die dmesg ausspuckt. Google sagt dazu: Platte/Hardware defekt. Andere Tools sagen: Alles gut.

Ja was denn nun? Hat einer einen Tipp für mich?

Gruß
Alex

[oln]

Moin,

Jetzt werden viele "Backup hilft" schreien....
Ja, das ist so ne Sache. Wie viele Backups eines 4TB Systems, von dem etwas über 2TB belegt sind passen auf eine 4TB Backup-Platte?
Ich hab auch nicht die Ressourcen um mehrere Backups abzulegen. D.h. eines muss erstmal reichen.

bei einem inkrementellen Backup passen da einige rauf. Aber egal.

Ich würde auch segen, dass eine Platte einen Schuss hat. Was du machen kannst, ist das System komplett neu aufsetzen und hoffen, dass das es nur das Software-Raid war. Dann Backup zurück und gut ist es.

[Tintom]

Mich würden die Ausgaben von smartctl interessieren. Was sagt smartctl -a für jede der beiden Platten?

[hikaru]

Bei nur einer Redundanz ist im Zweifelsfall nicht festzustellen, welche der Platten fehlerhaft ist, so lange auch die fehlerhafte Platte einen plausiblen Zustand liefert. Bei zwei Redundanzen (sprich: RAID1 aus drei HDDs) ließen sich solche Grenzfälle theoretisch erkennen.* Ob das auch implementiert ist weiß ich allerdings nicht.

SMART kann prinzipiell keine Aussage darüber treffen, ob eine Platte in Ordnung ist. Es könnte einen Hinweis auf einen Defekt liefern, aber das ist nicht das Selbe.

Es wird nicht ganz klar ob du bereits ein Backup hast, aber nochmal zur Erinnerung: Ein RAID ist kein Backup. Es kann höchstens ein Teilaspekt eines Backupkonzepts sein. Meine Vorstellung eines sinnvollen Backupkonzepts hatte ich mal hier niedergeschrieben. [1]

2TB in 10h sieht auf den ersten Blick zu wenig aus. Das sind 55MB/s. Von einer 3,5"-HDD sollten etwa 150MB/s zu erwarten sein, von einer 2,5"-HDD etwa 100MB/s. Allerdings gibt es diverse Faktoren die hier zu berücksichtigen sind. Falls du überwiegend kleine Dateien hast (Bilder, Textdokumente, Musik), dann drückt das die Übertragungsraten erheblich. Auch könnte es auf der Übertragungsstrecke einen Flaschenhals geben. Frühe USB-3.0-Controller limitierten gern bei 60MB/s, oder wurden von einer langsamen CPU ausgebremst.


*) Es sei denn, zwei Datenträger sind gleichzeitig defekt und liefern trotzdem plausible Ergebnisse. Kriminell würde es, wenn sie auch noch exakt den selben plausiblen Fehler liefern. Dann würde nämlich der intakte Datenträger defekt erscheinen.
[1] viewtopic.php?f=13&t=180947&start=15#p1272595

[alex0801]

@oln

Ja, inkrementell würde prinzipiell gehen, aber ich hab da teils auch fette Images drauf liegen die tatsächlich benutzt werden. Inkrementell innerhalb einer 500GB File... schwierig.

@Tintom

Bitte ... Diverse Tools (auch der gnome disk manager) meinten, alles wäre im Rahmen...

Code: Alles auswählen

martctl 7.2 2020-12-30 r5155 [x86_64-linux-5.10.0-8-amd64] (local build)
Copyright (C) 2002-20, Bruce Allen, Christian Franke, www.smartmontools.org

=== START OF INFORMATION SECTION ===
Model Family:     Seagate BarraCuda 3.5
Device Model:     ST4000DM004-2CV104
Serial Number:    ZFN1XXXX
LU WWN Device Id: 5 000c50 0b47536d1
Firmware Version: 0001
User Capacity:    4.000.787.030.016 bytes [4,00 TB]
Sector Sizes:     512 bytes logical, 4096 bytes physical
Rotation Rate:    5425 rpm
Form Factor:      3.5 inches
Device is:        In smartctl database [for details use: -P show]
ATA Version is:   ACS-3 T13/2161-D revision 5
SATA Version is:  SATA 3.1, 6.0 Gb/s (current: 3.0 Gb/s)
Local Time is:    Wed Sep 29 16:44:11 2021 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:  (0x00)	Offline data collection activity
					was never started.
					Auto Offline Data Collection: Disabled.
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: 		(    0) seconds.
Offline data collection
capabilities: 			 (0x73) SMART execute Offline immediate.
					Auto Offline data collection on/off support.
					Suspend Offline collection upon new
					command.
					No 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: 	 (   1) minutes.
Extended self-test routine
recommended polling time: 	 ( 484) minutes.
Conveyance self-test routine
recommended polling time: 	 (   2) minutes.
SCT capabilities: 	       (0x30a5)	SCT Status supported.
					SCT Data Table supported.

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   081   047   006    Pre-fail  Always       -       134417877
  3 Spin_Up_Time            0x0003   097   096   000    Pre-fail  Always       -       0
  4 Start_Stop_Count        0x0032   100   100   020    Old_age   Always       -       28
  5 Reallocated_Sector_Ct   0x0033   100   100   010    Pre-fail  Always       -       0
  7 Seek_Error_Rate         0x000f   092   060   045    Pre-fail  Always       -       1682007762
  9 Power_On_Hours          0x0032   075   075   000    Old_age   Always       -       22167 (1 124 0)
 10 Spin_Retry_Count        0x0013   100   100   097    Pre-fail  Always       -       0
 12 Power_Cycle_Count       0x0032   100   100   020    Old_age   Always       -       24
183 Runtime_Bad_Block       0x0032   097   097   000    Old_age   Always       -       3
184 End-to-End_Error        0x0032   100   100   099    Old_age   Always       -       0
187 Reported_Uncorrect      0x0032   100   100   000    Old_age   Always       -       0
188 Command_Timeout         0x0032   100   098   000    Old_age   Always       -       24 24 24
189 High_Fly_Writes         0x003a   100   100   000    Old_age   Always       -       0
190 Airflow_Temperature_Cel 0x0022   060   044   040    Old_age   Always       -       40 (Min/Max 35/40)
191 G-Sense_Error_Rate      0x0032   100   100   000    Old_age   Always       -       0
192 Power-Off_Retract_Count 0x0032   100   100   000    Old_age   Always       -       823
193 Load_Cycle_Count        0x0032   100   100   000    Old_age   Always       -       947
194 Temperature_Celsius     0x0022   040   056   000    Old_age   Always       -       40 (0 25 0 0 0)
195 Hardware_ECC_Recovered  0x001a   081   064   000    Old_age   Always       -       134417877
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       -       4
240 Head_Flying_Hours       0x0000   100   253   000    Old_age   Offline      -       21906h+54m+13.919s
241 Total_LBAs_Written      0x0000   100   253   000    Old_age   Offline      -       48537085402
242 Total_LBAs_Read         0x0000   100   253   000    Old_age   Offline      -       265005866896

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 without error       00%     21555         -
# 2  Extended offline    Interrupted (host reset)      90%     21541         -
# 3  Short offline       Completed without error       00%     21541         -
# 4  Extended offline    Completed without error       00%       433         -
# 5  Short offline       Completed without error       00%       419         -

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.






smartctl 7.2 2020-12-30 r5155 [x86_64-linux-5.10.0-8-amd64] (local build)
Copyright (C) 2002-20, Bruce Allen, Christian Franke, www.smartmontools.org

=== START OF INFORMATION SECTION ===
Model Family:     Seagate BarraCuda 3.5
Device Model:     ST4000DM004-2CV104
Serial Number:    ZFN1XXXX
LU WWN Device Id: 5 000c50 0b4759dae
Firmware Version: 0001
User Capacity:    4.000.787.030.016 bytes [4,00 TB]
Sector Sizes:     512 bytes logical, 4096 bytes physical
Rotation Rate:    5425 rpm
Form Factor:      3.5 inches
Device is:        In smartctl database [for details use: -P show]
ATA Version is:   ACS-3 T13/2161-D revision 5
SATA Version is:  SATA 3.1, 6.0 Gb/s (current: 6.0 Gb/s)
Local Time is:    Wed Sep 29 16:53:18 2021 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
See vendor-specific Attribute list for marginal Attributes.

General SMART Values:
Offline data collection status:  (0x00)	Offline data collection activity
					was never started.
					Auto Offline Data Collection: Disabled.
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: 		(    0) seconds.
Offline data collection
capabilities: 			 (0x73) SMART execute Offline immediate.
					Auto Offline data collection on/off support.
					Suspend Offline collection upon new
					command.
					No 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: 	 (   1) minutes.
Extended self-test routine
recommended polling time: 	 ( 482) minutes.
Conveyance self-test routine
recommended polling time: 	 (   2) minutes.
SCT capabilities: 	       (0x30a5)	SCT Status supported.
					SCT Data Table supported.

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   061   006    Pre-fail  Always       -       1705777
  3 Spin_Up_Time            0x0003   097   096   000    Pre-fail  Always       -       0
  4 Start_Stop_Count        0x0032   100   100   020    Old_age   Always       -       27
  5 Reallocated_Sector_Ct   0x0033   100   100   010    Pre-fail  Always       -       0
  7 Seek_Error_Rate         0x000f   092   060   045    Pre-fail  Always       -       1722941949
  9 Power_On_Hours          0x0032   075   075   000    Old_age   Always       -       22166 (176 152 0)
 10 Spin_Retry_Count        0x0013   100   100   097    Pre-fail  Always       -       0
 12 Power_Cycle_Count       0x0032   100   100   020    Old_age   Always       -       23
183 Runtime_Bad_Block       0x0032   100   100   000    Old_age   Always       -       0
184 End-to-End_Error        0x0032   100   100   099    Old_age   Always       -       0
187 Reported_Uncorrect      0x0032   098   098   000    Old_age   Always       -       2
188 Command_Timeout         0x0032   100   100   000    Old_age   Always       -       0 0 0
189 High_Fly_Writes         0x003a   100   100   000    Old_age   Always       -       0
190 Airflow_Temperature_Cel 0x0022   061   040   040    Old_age   Always   In_the_past 39 (Min/Max 35/39)
191 G-Sense_Error_Rate      0x0032   100   100   000    Old_age   Always       -       0
192 Power-Off_Retract_Count 0x0032   100   100   000    Old_age   Always       -       840
193 Load_Cycle_Count        0x0032   100   100   000    Old_age   Always       -       944
194 Temperature_Celsius     0x0022   039   060   000    Old_age   Always       -       39 (0 25 0 0 0)
195 Hardware_ECC_Recovered  0x001a   100   064   000    Old_age   Always       -       1705777
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
240 Head_Flying_Hours       0x0000   100   253   000    Old_age   Offline      -       22040h+46m+29.426s
241 Total_LBAs_Written      0x0000   100   253   000    Old_age   Offline      -       56198972954
242 Total_LBAs_Read         0x0000   100   253   000    Old_age   Offline      -       252761402545

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: 15794 hours (658 days + 2 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 53 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 08 ff ff ff 4f 00  40d+23:20:51.748  READ FPDMA QUEUED
  60 00 08 ff ff ff 4f 00  40d+23:20:51.748  READ FPDMA QUEUED
  60 00 08 ff ff ff 4f 00  40d+23:20:51.748  READ FPDMA QUEUED
  60 00 08 ff ff ff 4f 00  40d+23:20:51.748  READ FPDMA QUEUED
  60 00 08 ff ff ff 4f 00  40d+23:20:51.747  READ FPDMA QUEUED

Error 1 occurred at disk power-on lifetime: 15794 hours (658 days + 2 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 53 00 ff ff ff 0f  Error: WP 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
  -- -- -- -- -- -- -- --  ----------------  --------------------
  61 00 08 ff ff ff 4f 00  40d+23:20:51.362  WRITE FPDMA QUEUED
  60 00 00 ff ff ff 4f 00  40d+23:20:51.341  READ FPDMA QUEUED
  60 00 00 ff ff ff 4f 00  40d+23:20:51.340  READ FPDMA QUEUED
  ea 00 00 00 00 00 a0 00  40d+23:20:51.321  FLUSH CACHE EXT
  61 00 08 ff ff ff 4f 00  40d+23:20:51.320  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%     21553         -
# 2  Extended offline    Completed without error       00%       432         -
# 3  Short offline       Completed without error       00%       418         -

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.

@hikaru
Ich weiß, das RAID selbst ist kein Backup. Das RAID ist mein redundantes Plattensystem für meinen kleinen aber feinen Home-Server. Backups mach ich immer wieder manuell angestoßen auf eine weitere Platte. Leider noch keine automatischen (noch zu vile Setenabhängigkeiten die das Backup stören würden.... Kommt aber noch...)

SMART macht ja ein Self-Test. Und soweit ich weiß, testet es im long-test Fall auch die einzelnen Sektoren (dauert bei 4TB viele Stunden...). Da gab es bisher keine Fehler. Auf keiner der Platten.

Habs mittlerweile geschafft ein neues/frisches Backup des ganzen Systems zu machen. Hab noch ein paar mal fsck laufen lassen und ein paar vermeintlich defekte Ordner/Dateien gelöscht (was wohl nicht geklappt hat, aber betroffenen sind nur unwichtigere Daten). Beim kopieren ist aufgefallen, dass meist Richtung 100-180MB/sek kopiert wurde (an und für sich recht gut bis sehr gut), bei manchen Files er aber massiv eingebrochen ist. Hatte da ein einige Gigabyte großes Image beobachtet wie es zwischendrin mit nur mit <1MB/sek kopiert hat... Das schwankte dann immer wieder stark (innerhalb dieser einen großen Datei), bis es schließlich wieder mit >100MB kopiert hat. Während dessen gab es über dmesg nur ext4 fehler zu sehen. Keine sonst üblichen /dev/sdx Fehler, wie man sie eigentlich von Hardware-defekten bei Platten kennt.

Tippe aktuell noch auf einen seltsamen ext4-Dateisystemschaden. Zwei neue Platten sind unterwegs, kommen am Freitag. Dann werde ich das nochmal genauer untersuchen und das RAID auf den neuen Platten "from scratch" aufsetzen. Dieses mal vielleicht auch mit XFS statt EXT4 (bin noch unsicher).
Dann hab ich die "betroffenen" Platten zu weiteren intensiven Tests frei und kann sie auch einzeln testen.. Will unbedingt wissen woran das jetzt lag... Filesystem oder Hardware.

Danke soweit für die Antworten...

[alex0801]

Neue Platten sind mittlerweile drin und Backup ist auf dem neuen RAID1 (dieses mal mit XFS statt Ext4) wiederhergestellt.

Mit bisher keinem Testtool konnte ich bei den bisherigen Platten einen Defekt feststellen. Das ist mehr als seltsam. Denn das würde heißen, dass sich das ext4 Dateisystem im SoftRAID1 aus bisher ungeklärten Gründen in einen Zustand buchsiert hat, aus dem es nicht wieder raus gekommen ist.

Bin noch auf der Suche nach einem passenden Tool das die Platte bis auf's letzte Bit füllt und die Daten dann wieder liest. Nur um sicher zu gehen dass alle Ecken und Enden noch vollständig funktionieren.

Als "mögliche" Fehlerquelle konnte ich mit smartctl immerhin aus machen, dass eine der beiden Platten knapp 300min über der vom Hersteller angegebenen Maximaltemperatur von 60°C war. Ob das aber gleich einen Schaden hinterlassen hat der immer noch vorliegt.... kein Plan, würde das gerne verifizieren.

Hat da jemand einen Tipp?

Gruß
Alex

[Tintom]

Neue Platten sind mittlerweile drin und Backup ist auf dem neuen RAID1 (dieses mal mit XFS statt Ext4) wiederhergestellt.

Warum hast du dich ausgerechnet für XFS entschieden? Hattest du spezielle Gründe dafür?

Bin noch auf der Suche nach einem passenden Tool das die Platte bis auf's letzte Bit füllt und die Daten dann wieder liest. Nur um sicher zu gehen dass alle Ecken und Enden noch vollständig funktionieren.

Der „Klassiker“ für so etwas ist badblocks mit dem Schalter -w. Der Befehl schreibt Daten in einen Block und liest sie anschließend wieder. Die auf der Platte befindlichen Daten werden dadurch überschrieben. Da du die Platten jetzt schon ersetzt hast, kannst du die alten aus dem bisherigen RAID herausnehmen (wenn nicht sowieso schon geschehen) und diese dann parallel testen, der Befehl nimmt abhängig von der Festplattengröße nämlich einiges an Zeit in Anspruch.

[MSfree]

Neue Platten sind mittlerweile drin und Backup ist auf dem neuen RAID1 (dieses mal mit XFS statt Ext4) wiederhergestellt.

Das mit XFS solltest du dir vielleicht nochmal überlegen. Ich hatte in der Vergangenheit mehrfach Probleme mit XFS. Das ging soweit, daß z.B. nach einem Stromausfall das Dateisystem soweit zerstört war, daß es sich durch die Reperaturmechanismen nicht rekonstruieren ließ. Im Vergleich dazu scheinen mir ext3 und ext4 sehr viel robuster zu seien.

Mit bisher keinem Testtool konnte ich bei den bisherigen Platten einen Defekt feststellen.

Das glaube ich gerne. Nicht von ungefähr haben aber Firmen wie Synology SMR-Platten aus ihrer Kompatibilitätsliste entfernt. Ich weiß zwar auch nicht, was genau mit SMR-Platten schief geht, sie sind aber sehr wahrscheinlich ungeeignet für RAID-Systeme.

Das ist mehr als seltsam. Denn das würde heißen, dass sich das ext4 Dateisystem im SoftRAID1 aus bisher ungeklärten Gründen in einen Zustand buchsiert hat, aus dem es nicht wieder raus gekommen ist.

RAID1 ist ja nur eine Plattenspiegelung, jede Platte für sich beinhaltet ein vollständiges Dateisystem, man kann auch jede Platte einzeln als degradiertes RAID1 mounten und mit fsck checken lassen. Ich denke nicht, daß ext4 hier ein Problem war/ist, sondern einfach die SMR-Platten das Problem sind.

[alex0801]

Warum XFS? Naja, es scheint - wie ext4 auch - seine Vor und Nachteile zu haben. EXT4 kenne ich seit vielen Jahren XFS noch nicht. Möchte damit nun Erfahrungen sammeln. Werde nun ein regelmäßiges Backup aufsetzen und das System noch besser monitoren. So kann jetzt XFS zeigen was es kann. Wenn's schief geht, geht ich eben zu ext4 zurück.

Badblocks schau ich mir nochmal an. Danke.

> Ich denke nicht, daß ext4 hier ein Problem war/ist, sondern einfach die SMR-Platten das Problem sind.

Naja, wenn ich keinen Defekt auf den beiden Platten finde/reproduzieren kann muss es an EXT4 gelegen haben, vermutlich ausgelöst durch ein seltsames Plattenverhalten. Wir werden sehen.

Zum Thema CMR vs. SMR bin ich auf diesen interessanten Artikel gestoßen: https://www.reichelt.de/magazin/ratgebe ... hen-zweck/

Gruß
Alex

[MSfree]

Naja, wenn ich keinen Defekt auf den beiden Platten finde/reproduzieren kann muss es an EXT4 gelegen haben, vermutlich ausgelöst durch ein seltsames Plattenverhalten.

Nein, das Dateisystem ist eben nicht das Problem, schon gar nicht bei RAID1.

SMR-Platten schreiben Daten überlappend auf die Platte, um die Datendichte und somit de Kapazität zu erhöhen. Dabei kann es vorkommen, daß nicht nur die neu hinzu kommenden Daten geschrieben werden müssen sondern auch die Nachbarspuren eingelesen und nochmals geschrieben werden müssen. Dadurch kann die Schreibgeschwindigkeit in die Knie gehen. Passiert das nur auf einer der beiden Platten im RAID1, ist eine Platte sehr viel schneller mit dem Schreibvorgang fertig als die andere. Wenn die Zeitdifferenze zwischen den Platten zu groß ist, wird das vom RAID-Algorythmus im Linuxkernel als Schreibfehler betrachtet, obwohl beide Platten völlig in Ordnung sind und keine S.M.A.R.T.-Auffälligkeiten zeigen.

Die Problematik ist also unabhängig vom Dateisystem und würde auch mit XFS, ZFS, btrfs, VFAT ... auftreten.

[alex0801]

Also wenn ein Schreibvorgang nicht vollständig ausgeführt wird, dann sollten die Daten im Dateisystem auch nicht als "geschrieben" markiert werden.

Das RAID sorgt ja unabhängig vom Dateisystem dafür, dass die Daten auf beiden Platten abgelegt werden. Wenn ich jetzt also her gehe und dem Dateisystem sage: "Schreibe bitte XYZ", und das RAID die Daten nicht innerhalb einer vorgegebenen Zeit auf die Platten schreiben kann (weil eine warum auch immer langsamer ist), dann sollte der Kernel doch den Schreibvorgang als "nicht erfolgreich" an das Dateisystem zurück melden. Und demnach sollte auch nichts kaputt sein. Weder das Dateisystem, noch die Platten.

Was ich aber auf meinem EXT4 RAID1 hatte: Dateien die weder gelesen noch gelöscht werden konnten und die ein "fsck" auch nicht reparieren konnte.

WIE das zustande gekommen ist, ist ungeklärt. Aber ich halte es für fragwürdig wenn ein Schreibvorgang vom Dateisystem als "alles klar, hat geklappt, brauchst dir keine Sorgen machen" abgetan wird, und der Kernel darunter noch mit den Platten kämpft und in einen Schreibfehler läuft, welcher nicht zurück an das Dateisystem gemeldet wird. Okay, die meisten Mounts sind async, d.h. da wird nicht final beim Schreiben auf ein OK von der Hardware gewartet. Aber sollte selbst bei async nicht irgend eine Feedback-Loop existieren die Hardware Fehler zurück meldet, so dass man noch irgendwie drauf reagieren kann? Weiß da einer was?

Da könnte ja "gott weiß was" schief gehen und der Schreibende bzw. das Dateisystem bekommt das nie mit...Erst wenn das wieder gelesen oder verändert werden soll. Und selbst wenn: Auf einer der Platten hat es ja geklappt. Könnte man ja auf Block-Ebene wieder auf die Platte syncen und damit beide wieder in den selben Zustand bringen.

Und selbst wenn: Wenn beim Zugriff auf einen "kaputten" Bereich festgestellt wird: "Hoppla, da geht was nicht": Sollte da nicht ein fsck in der Lage sein das Problem zu heben? Erst recht wenn es gar kein Hardware-Schaden ist? Im Worst-Case sind die Daten futsch, ja. Aber fsck sollte es doch schaffen die betroffenen Dateien und Verzeichnisse nach der "reparatur" und dem "verschieben was noch zu retten ist nach lost+found" die Einträge zu löschen, so dass der Fehler erstmal behoben ist?!

[MSfree]

Was ich aber auf meinem EXT4 RAID1 hatte: Dateien die weder gelesen noch gelöscht werden konnten und die ein "fsck" auch nicht reparieren konnte.

Ich hätte zumindest versucht, die Platten einzeln, also nicht im RAID1, zu checken. Vermutlich hätte man dann zumindest auf einer der beiden Platten wieder eine Konsistenz herstellen können, inklusive der nicht mehr löschbaren Dateien.

Okay, die meisten Mounts sind async, d.h. da wird nicht final beim Schreiben auf ein OK von der Hardware gewartet.

Genau das ist das Problem. Wenn eine Anwendung eine Datei schreibt, wartet diese nur, bis die Datei im erfolgreich Dateisystemcache gelandet ist. Was beim Schreibvorgang aus dem Cache zum Datenträger passiert, bekommt die Anwendung nicht mehr mit, kann also auch keinen Fehler anzeigen.

Aber sollte selbst bei async nicht irgend eine Feedback-Loop existieren die Hardware Fehler zurück meldet, so dass man noch irgendwie drauf reagieren kann?

Nein, da gibt es kein Feedback. Du darfst nicht vergessen, daß sowas auch im bildschirmlosen Serverbetrieb funktionieren muß. Da gibt es aber keinen, der auf ein Popup-Fenster reagieren könnte. Der interaktive Betrieb spielt hier ja keine Sonderrolle, bei dem alles mögliche an die GUI gemeldet wird, die verhält sich genauso wie beim Serverbetrieb, nämlich stumm.

Allerdings schreibt der Kernel fleißig Logs, die man mit dmesg und/oder journalctl ansehen kann. Da wirst du vermutlich fündig, aber eben nicht sofort beim Auftreten eines Fehlers sondern ggfls. erst Wochen später, wenn du nicht regelmässiger in die Logs schaust.

[alex0801]

Ich hatte ja zu Anfang das Problem, dass eine der Platten aus dem RAID Verbund geflogen ist. Spätestens mit dem "wieder einhängen" in den Verbund hätte sich das Problem ja in Luft auflösen müssen. Denn:

Wenn eine Anwendung eine Datei schreibt, wartet diese nur, bis die Datei im erfolgreich Dateisystemcache gelandet ist. Was beim Schreibvorgang aus dem Cache zum Datenträger passiert, bekommt die Anwendung nicht mehr mit, kann also auch keinen Fehler anzeigen.

Korrekt. Es geht auch nicht um die Anzeige des Fehler beim User oder in der Anwendung. Aber wenn der Kernel meldet: "Hoppla, konnte ich doch nicht schreiben", dann sollte er das doch wengistens dem Dateisystem melden, so das das Filesystem nicht von falschen Tatsachen ausgeht und Einträge beherbergt die schlicht "kaputt" sind, oder? So viel "selbstheilung" ist ja zu erwarten von einem modernen Kernel und Dateisystem.

Allerdings schreibt der Kernel fleißig Logs, die man mit dmesg und/oder journalctl ansehen kann. Da wirst du vermutlich fündig, aber eben nicht sofort beim Auftreten eines Fehlers sondern ggfls. erst Wochen später, wenn du nicht regelmässiger in die Logs schaust.

Wenn es tatsächlich zwischen Kernel und Dateisystem-Layer keine Feedback Loop gibt die in irgend einer Weise Fehler behandelt/korrigiert, dann würde ich erwarten dass es entweder ein Tool gibt das die Logs überwacht und mich per Mail benachrichtigt, oder dass dieser Umstand sooooo selten ist, dass es quasi ausgeschlossen ist dass er Auftritt.

Ich betreibe jetzt seit >15 Jahren Software-RAIDs und kleinere bis mittlere Linux-Server (mehr privat als beruflich) und fummle insgesamt schon seit SuSE Linux 5.3 an Linux rum. Aber sowas (unlogisches/undurchdachtes) ist mir noch nicht unter gekommen.

[MSfree]

Wenn es tatsächlich zwischen Kernel und Dateisystem-Layer keine Feedback Loop gibt die in irgend einer Weise Fehler behandelt/korrigiert...

Diese Fehler werden doch behandelt, die Platte ist ja wohl aus deinem RAID, wie du selbst schreisbt, rausgeflogen.

Bei einem Hardwarefefekt wird halt keine "Selbstheilung" mehr versucht. Die wäre bei einem Defekt ja auch ziemlich wenig erfolgversprechend.

dann würde ich erwarten dass es entweder ein Tool gibt das die Logs überwacht und mich per Mail benachrichtigt

Gibt es, muß halt installiert und konfiguriert werden.

[alex0801]

Diese Fehler werden doch behandelt, die Platte ist ja wohl aus deinem RAID, wie du selbst schreisbt, rausgeflogen.

Das ist 1x passiert. Fehler hatte ich aber offenbar mehrere an verschiedenen Stellen im Dateisystem (die von unserschiedlichen Anwendungen zu unterschiedlichen Zeiten bedient wurden).
Also so 100% wasserdicht ist das nicht.

Bei einem Hardwarefefekt wird halt keine "Selbstheilung" mehr versucht. Die wäre bei einem Defekt ja auch ziemlich wenig erfolgversprechend.

Korrekt, der Hardwaredefekt ist aber noch nicht nachgewiesen.

Gibt es, muß halt installiert und konfiguriert werden.

Hab schon diverse Jobs die mir Cron abnimmt und Logfiles auf die unterschiedlichsten Dinge überwacht. Aber hinsichtlich "Dateisystem Schwierigkeiten" hab ich noch nix gesehen.
Würde ja die bestehenden Tools entsprechend anpassen dass sie auch nach diesen Log-Meldungen ausschau halten. Aber noch steh ich da im dunkeln was da im Log genau zu erwarten ist, so dass ich da kein RegEx draus formen kann.

Hast du einen Tipp für mich? Also zwecks Tooling oder Log-Medung?

[MSfree]

Korrekt, der Hardwaredefekt ist aber noch nicht nachgewiesen.

Die Platten sind vermutlich auch gar nicht defekt. SMR-Platten verhalten sich aber nicht deterministisch. Und wenn Schreibvorgänge zu lange dauern, wird die betroffene Platte vom Kernel als defekt betrachtet. Daß die Platte dann, weil die auch über Cache verfügt, dennoch Restdaten auf die Platte schreibt, die dann eventuell das Dateisystem zerbröseln, kann der Kernel nicht mehr mitbekommen.

Wie gesagt, Synology hat SMR-Platten explizit inkompatibel gelistet, und ich denke, die wissen, warum:
https://www.heise.de/hintergrund/Netzwe ... 19151.html
https://www.heise.de/news/NAS-Festplatt ... 77727.html
Das Betriebssystem, das auf den Synologys läuft, ist Linux mit genau dem gleichen RAID-Code, den du mit deinem Soft-RAID verwendest.

Würde ja die bestehenden Tools entsprechend anpassen dass sie auch nach diesen Log-Meldungen ausschau halten. Aber noch steh ich da im dunkeln was da im Log genau zu erwarten ist

Hast du die alten Logs noch? Dann schau dort mal nach IO-Fehlern und/oder dem Namen des Raidverbunds (bei mir z.B. /dev/md0).