Unmountable: Wrong or no filesystem

[mgutt]

Ok, dann bitte wie empfohlen die xfs logs entfernen, dann noch mal Reparatur versuchen und wenn das auch nicht hilft, mit testdisk sein Glück versuchen.

 

Wegen der nicht gemeldeten kaputten Disk: Steht denn was in den Logs von vor dem Update? Kannst du mir auch gerne per PN senden.

[Smolo]

3 hours ago, hawihoney said:

 

Und genau so muss es sein.

 

Disk4 wird nun emuliert. Das degradierte Array zeigt nun "seinen" aktuellen Wissensstand. Dieser unterscheidet sich nicht von dem "Wissen" mit defekter Disk4.

 

Jetzt mal auf die emulierte Disk4 zugreifen (ls -la /mnt/disk4 oder mc aufrufen). Was siehst Du?

Danach guckst Du was den Inhalt des Arrays angeht und machst ggfs. ein Backup.

 

Das Problem ist das in den Ordnern nichts enthalten ist einfach nur gähnende Leere.

[Smolo]

2 hours ago, ich777 said:

So, hatte kurz Zeit, hab es auch kompiliert aber ich hab dann mal mit un-get gesucht und auch gefunden.

Um es in gang zu bekommen einfach un-get installieren und dann:

un-get update
un-get install testdisk libewf

(libewf brauchst damit testidsk läuft)

 

Danach kannst:

testdisk

ganz normal ausführen.

 

Zum löschen einfach wieder:

un-get remove testdisk libewf

 

Super vielen Dank mit dem Thema sehe ich wengistens wo er steht....Testdisk unter Windows mit USB angeschlossen hat keine Anzeige gehabt vom aktuellen Status jetzt lasse ich noch mal den Depper Search laufen. 

[Smolo]

2 hours ago, mgutt said:

Ok, dann bitte wie empfohlen die xfs logs entfernen, dann noch mal Reparatur versuchen und wenn das auch nicht hilft, mit testdisk sein Glück versuchen.

 

Wegen der nicht gemeldeten kaputten Disk: Steht denn was in den Logs von vor dem Update? Kannst du mir auch gerne per PN senden.

Die fehlenden Daten sind extrem wichtig ich bin grad echt unschlüssig was ich tun soll. Irgendwelche Aktionen auf der Platte durchführen und in Kauf nehmen das die Daten überschrieben werden oder volles Risiko fahren und hoffen das die Struktur wiederhergestellt werden kann? Was mich in dem Fall so wundert das ich in der emulierten Disk leere Verzeichnisse bekomme auf nahezu TopLevel Ebene.

 

Kennt jemand von euch ein gutes Datenwiederherstellungstool auf OS Basis?

 

 So wie es aussieht habe ich beim Stöbern in den Logs folgendes entdeckt:

Nov 10 00:36:09 Sugo kernel: XFS (md4): Corruption detected. Unmount and run xfs_repair
Nov 10 00:36:09 Sugo kernel: XFS (md4): Failed to recover intents
Nov 10 00:36:09 Sugo kernel: XFS (md4): Filesystem has been shut down due to log error (0x2).
Nov 10 00:36:09 Sugo kernel: XFS (md4): Please unmount the filesystem and rectify the problem(s).
Nov 10 00:36:09 Sugo kernel: XFS (md4): Ending recovery (logdev: internal)
Nov 10 00:36:09 Sugo kernel: XFS (md4): log mount finish failed
Nov 10 00:36:09 Sugo root: mount: /mnt/disk4: mount(2) system call failed: Structure needs cleaning.
Nov 10 00:36:09 Sugo root:        dmesg(1) may have more information after failed mount system call.
Nov 10 00:36:09 Sugo  emhttpd: shcmd (31): exit status: 32
Nov 10 00:36:09 Sugo  emhttpd: /mnt/disk4 mount error: Wrong or no file system
Nov 10 00:36:09 Sugo  emhttpd: shcmd (34): umount /mnt/disk4
Nov 10 00:36:09 Sugo root: umount: /mnt/disk4: not mounted.
Nov 10 00:36:09 Sugo  emhttpd: shcmd (34): exit status: 32
Nov 10 00:36:09 Sugo  emhttpd: shcmd (35): rmdir /mnt/disk4
Nov 10 00:36:09 Sugo  emhttpd: shcmd (36): mkdir -p /mnt/cache
Nov 10 00:36:09 Sugo  emhttpd: /mnt/cache uuid: 73f566c2-b85d-431a-93b1-51ef3f3a2206
Nov 10 00:36:09 Sugo  emhttpd: /mnt/cache (null)
Nov 10 00:36:09 Sugo  emhttpd: /mnt/cache (null)
Nov 10 00:36:09 Sugo  emhttpd: /mnt/cache (null)
Nov 10 00:36:09 Sugo  emhttpd: /mnt/cache (null)
Nov 10 00:36:09 Sugo  emhttpd: /mnt/cache found: 2
Nov 10 00:36:09 Sugo  emhttpd: /mnt/cache extra: 0
Nov 10 00:36:09 Sugo  emhttpd: /mnt/cache missing: 0

 

D.h. direkt nach dem Update hat es das Dateisystem zerlegt?

[hawihoney]

15 minutes ago, Smolo said:

Das Problem ist das in den Ordnern nichts enthalten ist einfach nur gähnende Leere.

 

Aber Du siehst Ordner mit "ls -la /mnt/disk4/"? Und Du kannst mit "cd /mnt/disk4/Ordner/" in einen dieser Ordner hinein wechseln und dann mit "ls -la" den (leeren) Inhalt von diesem Ordner aufrufen ohne das eine Fehlermeldung erscheint?

 

Das ist wichtig, denn das bedeutet, dass die emulierte Disk4 offensichtlich nicht ganz im Eimer ist. Der Inhalt von Disk4 im Array mag dann weg sein, aber die Disk4 muss nicht zum Abschluss neu eingerichtet werden.

 

Wenn ja: Alle weitergehenden Arbeiten konzentrieren sich jetzt auf die außerhalb des Arrays stehende Disk4. Alles was dort rekonstruiert werden kann, könnte auf die emulierte Disk kopiert werden. Letzteres nur wenn Du wie oben geschrieben Ordner unterhalb von /mnt/disk4 siehst.

 

Zieh dann aber jedes mal ein Backup für die Zwischenstände. Ist ja nur eine 4 TB Disk

 

[JorgeB]

Zeroing the log is IMHO your best bet but since the SSD is also being emulated you can repair that filesystem instead if you want and leave the original device untouched:

 

-start the array in maintenance mode and type

xfs_repair -vL /dev/md4

-when done stop array

-start array in normal mode and the emulated disk4 should now mount, check contents

[Smolo]

14 minutes ago, hawihoney said:

 

Aber Du siehst Ordner mit "ls -la /mnt/disk4/"? Und Du kannst mit "cd /mnt/disk4/Ordner/" in einen dieser Ordner hinein wechseln und dann mit "ls -la" den (leeren) Inhalt von diesem Ordner aufrufen ohne das eine Fehlermeldung erscheint?

 

Das ist wichtig, denn das bedeutet, dass die emulierte Disk4 offensichtlich nicht ganz im Eimer ist. Der Inhalt von Disk4 im Array mag dann weg sein, aber die Disk4 muss nicht zum Abschluss neu eingerichtet werden.

 

Wenn ja: Alle weitergehenden Arbeiten konzentrieren sich jetzt auf die außerhalb des Arrays stehende Disk4. Alles was dort rekonstruiert werden kann, könnte auf die emulierte Disk kopiert werden. Letzteres nur wenn Du wie oben geschrieben Ordner unterhalb von /mnt/disk4 siehst.

 

Zieh dann aber jedes mal ein Backup für die Zwischenstände. Ist ja nur eine 4 TB Disk

 

Ja es erscheint kein Fehler und das Verzeichnis ist leer das ist so weit korrekt. Soweit mein aktuelles Verständnis reicht bin ich da aber doch doppelt gekniffen denn das bedeutet die Parity hält die Daten nicht vor und auf der Disk4 kann ich auch nicht direkt/indirekt zugreifen. Warum sollte ich jetzt Daten von DIsk4 rekonstrurieren und auf die emulierte Disk schreiben da bin ich gedanklich jetzt vollkommen raus vom Verständnis?

 

Das mit dem Backup ziehen ist leichter gesagt als getan....ich bin nicht Daheim wo mein ganzer IT Stuff liegt und hab hier nur einen alten Laptop mit einem USB Port🤪...baue grad Häuschen in Eigenleistung 500km entfernt  und die ganzen Baubilder liegen in dem Ordner weil ich diese noch nicht ins 3fach gesicherte Storage schieben konnte 😐

 

Wie ziehe ich denn am leichtesten unter Linux eine 1:1 Bit Kopie einer Platte direkt unter Unraid geht das auch in virtuelle Abbilder? Am liebsten würde ich die Platte zum Datenrestore einschicken es geht eigentlich nur um 50GB Bilder der Rest waren nur x fach gesicherte Kopien auf der Platte die sind mir total wurscht aber der Rest umso wichtiger.

[Smolo]

19 minutes ago, JorgeB said:

Zeroing the log is IMHO your best bet but since the SSD is also being emulated you can repair that filesystem instead if you want and leave the original device untouched:

 

-start the array in maintenance mode and type

xfs_repair -vL /dev/md4

-when done stop array

-start array in normal mode and the emulated disk4 should now mount, check contents

Does the XFS protocol now only refer to the emulated disk? Will I somehow get the discs back together when I run this?

[DataCollector]

1 hour ago, Smolo said:

Die fehlenden Daten sind extrem wichtig ich bin grad echt unschlüssig was ich tun soll. Irgendwelche Aktionen auf der Platte durchführen und in Kauf nehmen das die Daten überschrieben werden oder volles Risiko fahren und hoffen das die Struktur wiederhergestellt werden kann?

Wenn Dir Deien Dateien wichtig sind und kein Backup vorhanden ist und Du selber Erfolg nicht garantieren kannst:

Entwder Bitgenaue Kopie machen und nur damit arbeiten

oder gleich die Festplatte einem Datenretter übergeben (=teuer).

 

[JorgeB]

31 minutes ago, Smolo said:

Does the XFS protocol now only refer to the emulated disk? Will I somehow get the discs back together when I run this?

Since disk4 is currently being emulated running it on /dev/md4 won't touch the actual SSD, but it won't enable the device, just fix the filesystem on the emulated disk, but because of parity it will allow you to access the data there.

[mgutt]

1 hour ago, Smolo said:

Kennt jemand von euch ein gutes Datenwiederherstellungstool auf OS Basis?

Photorec, also auch von den Testdisk Leuten. Du kannst dich dann allerdings von den Dateinamen verabschieden. Bei XFS sind die nicht wiederherstellbar. Das geht nur bei BTRFS und dem Kommando btrfs restore.

 

Was du machen kannst, um die Disk nicht anfassen zu müssen:

 

dd if=/dev/sdb of=/mnt/disk1/sdb.img bs=128k

 

Dann hast du schon mal das Image von der kompletten Disk ohne Änderungen. Dieses Image könnte man nun mounten oder zb auch an eine VM als zweite vdisk übergeben. Wenn du zb mit knoppix die Disk analysieren willst.

 

 

[hawihoney]

40 minutes ago, Smolo said:

die Parity hält die Daten nicht vor

 

Du hast die Grundzüge der Parity nicht verstanden. Da wird nichts vorgehalten. Das ist kein Backup. Die Parity bietet Ausfallsicherheit.

 

Disk4 wurde aus dem Array entfernt. Die Parity und Disk1 sind in der Lage den aktuellen Stand der Disk4 zu emulieren. Was dort emuliert wird ist der Stand der Disk4 vor deren Entfernen.

 

Nun hast Du die physikalische Disk4 in Unassigned Devices eingebunden. Zusätzlich hast Du eine emulierte (virtuelle) Disk4 im Array. Mit beiden kann man arbeiten.

 

Wenn Du die Befehle von @JorgeB gegen /mnt/md4 ausführst, dann arbeitet das mit der emulierten (virtuellen) Disk4. Änderungen die sich dadurch ergeben werden sofort im Array hinterlegt.

 

Wenn Du irgendwelche Datenrettungs Maßnahmen an der physikalischen Disk4 ausführst, dann betrifft das zunächst nur die eine Festplatte. Sollten dadurch Dateien wieder erreichbar sein, dann kannst Du die aufs Array kopieren. Das landet dann zunächst auf der Parity und Disk1 sowie der emulierten Disk4. Auf eine richtige Disk4 landet das dann erst, wenn zum Abschluss aller Arbeiten wieder eine echte Festplatte als Disk4 ins Array gesteckt wird.

 

Ich würde gem. JorgeB vorgehen.

 

[Smolo]

12 minutes ago, hawihoney said:

 

Du hast die Grundzüge der Parity nicht verstanden. Da wird nichts vorgehalten. Das ist kein Backup. Die Parity bietet Ausfallsicherheit.

 

Ich habe mich falsch ausgedrückt das ist mir schon klar was die Parity macht in dem Kontext.

 

Das Problem ist doch das es mir wegen einem HW Fehler anscheinend das Dateisystem zerlegt hat und die Parity das nicht rafft und ohne Fehler durchläuft und das kann ich nicht verstehen an dieser Stelle.

[Smolo]

18 minutes ago, mgutt said:

Photorec, also auch von den Testdisk Leuten. Du kannst dich dann allerdings von den Dateinamen verabschieden. Bei XFS sind die nicht wiederherstellbar. Das geht nur bei BTRFS und dem Kommando btrfs restore.

 

Was du machen kannst, um die Disk nicht anfassen zu müssen:

 

dd if=/dev/sdb of=/mnt/disk1/sdb.img bs=128k

 

Dann hast du schon mal das Image von der kompletten Disk ohne Änderungen. Dieses Image könnte man nun mounten oder zb auch an eine VM als zweite vdisk übergeben. Wenn du zb mit knoppix die Disk analysieren willst.

 

Photorec hab ich schon gesehen eventuell zieh ich die Daten damit erstmal wenn möglich. Dateinamen sind egal Hauptsache der Content ist wieder da.

 

Bin erstmal aufm Bau muss da Abend weitermachen. Danke.

[hawihoney]

12 minutes ago, Smolo said:

Bin erstmal aufm Bau muss da Abend weitermachen.

 

Am Sonntag? Keine Nachbarn? Oder eine Neubausiedlung wo Sonntags alle arbeiten?

 

Haben vor vielen Jahren Sonntags einen Spaziergang durch ein benachbartes Neubaugebiet gemacht. Ein Haus war fertig - vermutlich keine Eigenleistungen. Die Bewohner des Hauses saßen im Garten. Und rundherum tobte der Baulärm - sogar mit Bagger. Meine Frau und ich schauten uns an und sagten "Das wären wir". Damals beschlossen wir entweder a.) ein gebrauchtes Haus in einer ausgebauten Siedlung zu kaufen und kernsanieren oder b.) kein Haus zu kaufen.

 

Viele Jahre später haben wir a.) gezogen. Obwohl wir alle Gewerke vertraglich auf Mo-Fr 08:00-17:00 verpflichtet hatten, wurden wir nahezu täglich in der Straße angeschrien. Nicht wegen des Baulärms, nein, wegen den liebgewonnenen Parkplätzen vor der Haustür. Die öffentliche Straße gehört ja angeblich anteilig zum Haus. In der Summe wollten uns das 6 (sechs) Eigentümer von benachbarten Häusern glaubhaft versichern. Willkommen in Absurdistan.

 

[mgutt]

9 minutes ago, hawihoney said:

Die öffentliche Straße gehört ja angeblich anteilig zum Haus. In der Summe wollten uns das 6 (sechs) Eigentümer von benachbarten Häusern glaubhaft versichern.

Ha ha genauso bei uns. Wir haben mit Viebrockhaus gebaut. Durch deren kurzen Bauzeit standen quasi jeden Tag 3 bis 6 Handwerker mit ihren Fahrzeugen in der Straße. Während der Keller gebaut wurde, fuhren die bei uns sogar durch den Wald, um die Kipplaster wenden zu können. Dafür wurde extra eine Sondergenehmigung eingeholt und der Wald sogar komplett neu mit Schotterweg ausgestattet. Die Polizei war trotzdem alle paar Tage da ^^ Bei uns war es allerdings nur ein Nachbar. Der fand es denke ich doof, dass wir in letzter Reihe direkt vor dem Wald gebaut haben, wo er vorher die letzte Reihe war. Der hat noch ewig Gerüchte gestreut ich würde Leute anzeigen usw. (denke mal er selbst war das). Hat aber mittlerweile das zeitliche gesegnet. Der gute Mann hatte wohl einfach zu viel Langeweile.

[Smolo]

Gewerke vergeben?! Das sind wir zwei Irren (Vater + me)  😁 Bis auf ein paar spezielle Themen (Dach, Putz) machen wir alles allein...hab dieses Jahr schon 80-100m³ Beton gepumpt wird ein Niedrigenergie/Passivhaus.

 

Nachbarn gibts nur bedingt ist ein Neubaugebiet 250m neben nem See. Wir sind eigentlich 18hx7 aufm Bau. Nur der Arzt 150m weiter hat sich mal etwas Lautstark beschwert als ich Sa 20.30 bei Regen die Fenster mit nem 250er Trennjäger bearbeitet hab😂

[Smolo]

Kurzes Update zu meiner Havarie.

 

Der Hinweis von @JorgeB die emulierte Platte über den nachfolgenden Befehl zu bereinigen war genau die richtige Lösung. Thanks JorgeB.

xfs_repair -vL /dev/md4

 

Natürlich auch an alle anderen vielen lieben Dank für den Support!

 

Zurück zum Thema mir stellen sich hier noch zwei entscheidende Fragen:

1) Es sieht zwar so aus als wenn die Daten wieder da sind aber genau Wissen kann ich es leider nicht. D.h. wenn es das XFS Dateisystem zerlegt kann es trotz Parität zu einem Datenverlust kommen soweit mein aktuelles Verständnis?

 

2) Ich mache zur Sicherheit noch eine 1:1 Kopie auf eine extra Platte außerhalb des Arrays die 16TB sind schon unterwegs. Aber wie hänge ich die SSD wieder ins Array rein einfach formierten und wieder als Disk 4 hinterlegen?

[mgutt]

7 hours ago, Smolo said:

Aber wie hänge ich die SSD wieder ins Array

Ich meine man kann eine defekte Disk nicht gegen sich selbst ersetzen. unRAID erkennt die ja an Hand der Seriennummer. Oder gibt es doch einen Weg?!

 

Ansonsten könntest du die SSD auf dem selben Weg reparieren. Die ist ja noch als /dev/sdb vorhanden. Das würde sich eh anbieten, damit man sie noch mal explizit testen kann BEVOR man sie wieder ins Array packt. Hast du mittlerweile syslog mirror aktiv? Schick auch gerne noch mal die Logs, dann schaue ich mal, ob die SSD immer noch Meldungen verursacht.

 

 

[Smolo]

Muss den Thread leider noch mal ausbuddeln.... kann damit jemand was anfangen?

 

Start einer Kopieraktion auf eine neue Platte die nur gemounted ist? Nach 1min kopierne = grätsche und Platte ist weg?
 

Dec 21 00:21:18 Sugo emhttpd: read SMART /dev/sdb
Dec 21 00:24:14 Sugo kernel: ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6 frozen
Dec 21 00:24:14 Sugo kernel: ata1.00: failed command: FLUSH CACHE EXT
Dec 21 00:24:14 Sugo kernel: ata1.00: cmd ea/00:00:00:00:00/00:00:00:00:00/a0 tag 7
Dec 21 00:24:14 Sugo kernel:         res 40/00:00:00:00:00/00:00:00:00:00/40 Emask 0x4 (timeout)
Dec 21 00:24:14 Sugo kernel: ata1.00: status: { DRDY }
Dec 21 00:24:14 Sugo kernel: ata1: hard resetting link
Dec 21 00:24:19 Sugo kernel: ata1: link is slow to respond, please be patient (ready=0)
Dec 21 00:24:24 Sugo kernel: ata1: found unknown device (class 0)
Dec 21 00:24:24 Sugo kernel: ata1: softreset failed (device not ready)
Dec 21 00:24:24 Sugo kernel: ata1: hard resetting link
Dec 21 00:24:29 Sugo kernel: ata1: link is slow to respond, please be patient (ready=0)
Dec 21 00:24:34 Sugo kernel: ata1: found unknown device (class 0)
Dec 21 00:24:34 Sugo kernel: ata1: softreset failed (device not ready)
Dec 21 00:24:34 Sugo kernel: ata1: hard resetting link
Dec 21 00:24:39 Sugo kernel: ata1: link is slow to respond, please be patient (ready=0)
Dec 21 00:24:44 Sugo kernel: ata1: found unknown device (class 0)
Dec 21 00:24:50 Sugo kernel: ata1: link is slow to respond, please be patient (ready=0)
Dec 21 00:25:09 Sugo kernel: ata1: softreset failed (device not ready)
Dec 21 00:25:09 Sugo kernel: ata1: limiting SATA link speed to 3.0 Gbps
Dec 21 00:25:09 Sugo kernel: ata1: hard resetting link
Dec 21 00:25:14 Sugo kernel: ata1: found unknown device (class 0)
Dec 21 00:25:14 Sugo kernel: ata1: softreset failed (device not ready)
Dec 21 00:25:14 Sugo kernel: ata1: reset failed, giving up
Dec 21 00:25:14 Sugo kernel: ata1.00: disable device
Dec 21 00:25:14 Sugo kernel: ata1: EH complete
Dec 21 00:25:14 Sugo kernel: sd 1:0:0:0: [sdb] tag#16 UNKNOWN(0x2003) Result: hostbyte=0x04 driverbyte=DRIVER_OK cmd_age=122s
Dec 21 00:25:14 Sugo kernel: sd 1:0:0:0: [sdb] tag#16 CDB: opcode=0x8a 8a 00 00 00 00 00 00 3c f7 00 00 00 0a 00 00 00
Dec 21 00:25:14 Sugo kernel: I/O error, dev sdb, sector 3995392 op 0x1:(WRITE) flags 0x104000 phys_seg 49 prio class 2
Dec 21 00:25:14 Sugo kernel: sd 1:0:0:0: [sdb] tag#17 UNKNOWN(0x2003) Result: hostbyte=0x04 driverbyte=DRIVER_OK cmd_age=0s
Dec 21 00:25:14 Sugo kernel: sd 1:0:0:0: [sdb] tag#17 CDB: opcode=0x8a 8a 00 00 00 00 00 00 3d 01 00 00 00 00 38 00 00
Dec 21 00:25:14 Sugo kernel: I/O error, dev sdb, sector 3997952 op 0x1:(WRITE) flags 0x100000 phys_seg 5 prio class 2
Dec 21 00:25:14 Sugo kernel: sd 1:0:0:0: [sdb] tag#18 UNKNOWN(0x2003) Result: hostbyte=0x04 driverbyte=DRIVER_OK cmd_age=122s
Dec 21 00:25:14 Sugo kernel: sd 1:0:0:0: [sdb] tag#18 CDB: opcode=0x35 35 00 00 00 00 00 00 00 00 00
Dec 21 00:25:14 Sugo kernel: I/O error, dev sdb, sector 15032387032 op 0x1:(WRITE) flags 0x9800 phys_seg 1 prio class 2
Dec 21 00:25:14 Sugo kernel: sd 1:0:0:0: [sdb] tag#19 UNKNOWN(0x2003) Result: hostbyte=0x04 driverbyte=DRIVER_OK cmd_age=0s
Dec 21 00:25:14 Sugo kernel: sd 1:0:0:0: [sdb] tag#19 CDB: opcode=0x8a 8a 00 00 00 00 00 00 3d 01 38 00 00 0a 00 00 00
Dec 21 00:25:14 Sugo kernel: I/O error, dev sdb, sector 3998008 op 0x1:(WRITE) flags 0x104000 phys_seg 168 prio class 2
Dec 21 00:25:14 Sugo kernel: sd 1:0:0:0: [sdb] tag#20 UNKNOWN(0x2003) Result: hostbyte=0x04 driverbyte=DRIVER_OK cmd_age=0s
Dec 21 00:25:14 Sugo kernel: sd 1:0:0:0: [sdb] tag#20 CDB: opcode=0x8a 8a 00 00 00 00 00 00 3d 0b 38 00 00 05 80 00 00
Dec 21 00:25:14 Sugo kernel: I/O error, dev sdb, sector 4000568 op 0x1:(WRITE) flags 0x104000 phys_seg 88 prio class 2
Dec 21 00:25:14 Sugo kernel: sd 1:0:0:0: [sdb] tag#21 UNKNOWN(0x2003) Result: hostbyte=0x04 driverbyte=DRIVER_OK cmd_age=0s
Dec 21 00:25:14 Sugo kernel: sd 1:0:0:0: [sdb] tag#21 CDB: opcode=0x8a 8a 00 00 00 00 00 00 3d 10 b8 00 00 08 48 00 00
Dec 21 00:25:14 Sugo kernel: I/O error, dev sdb, sector 4001976 op 0x1:(WRITE) flags 0x100000 phys_seg 70 prio class 2
Dec 21 00:25:14 Sugo kernel: sd 1:0:0:0: [sdb] tag#22 UNKNOWN(0x2003) Result: hostbyte=0x04 driverbyte=DRIVER_OK cmd_age=0s
Dec 21 00:25:14 Sugo kernel: sd 1:0:0:0: [sdb] tag#22 CDB: opcode=0x8a 8a 00 00 00 00 00 00 3d 19 00 00 00 05 b0 00 00
Dec 21 00:25:14 Sugo kernel: I/O error, dev sdb, sector 4004096 op 0x1:(WRITE) flags 0x104000 phys_seg 168 prio class 2
Dec 21 00:25:14 Sugo kernel: sd 1:0:0:0: [sdb] tag#23 UNKNOWN(0x2003) Result: hostbyte=0x04 driverbyte=DRIVER_OK cmd_age=0s
Dec 21 00:25:14 Sugo kernel: sd 1:0:0:0: [sdb] tag#23 CDB: opcode=0x8a 8a 00 00 00 00 00 00 3d 1e b0 00 00 05 80 00 00
Dec 21 00:25:14 Sugo kernel: I/O error, dev sdb, sector 4005552 op 0x1:(WRITE) flags 0x100000 phys_seg 88 prio class 2
Dec 21 00:25:14 Sugo kernel: sd 1:0:0:0: [sdb] tag#31 UNKNOWN(0x2003) Result: hostbyte=0x04 driverbyte=DRIVER_OK cmd_age=0s
Dec 21 00:25:14 Sugo kernel: sd 1:0:0:0: [sdb] tag#31 CDB: opcode=0x8a 8a 00 00 00 00 00 00 3d 24 30 00 00 0a 00 00 00
Dec 21 00:25:14 Sugo kernel: I/O error, dev sdb, sector 4006960 op 0x1:(WRITE) flags 0x104000 phys_seg 160 prio class 2
Dec 21 00:25:14 Sugo kernel: sd 1:0:0:0: [sdb] tag#0 UNKNOWN(0x2003) Result: hostbyte=0x04 driverbyte=DRIVER_OK cmd_age=0s
Dec 21 00:25:14 Sugo kernel: sd 1:0:0:0: [sdb] tag#0 CDB: opcode=0x8a 8a 00 00 00 00 00 00 3d 2e 30 00 00 06 00 00 00
Dec 21 00:25:14 Sugo kernel: I/O error, dev sdb, sector 4009520 op 0x1:(WRITE) flags 0x100000 phys_seg 96 prio class 2
Dec 21 00:25:14 Sugo kernel: XFS (sdb1): log I/O error -5
Dec 21 00:25:14 Sugo kernel: sdb: detected capacity change from 31251759104 to 0
Dec 21 00:25:14 Sugo kernel: sd 1:0:0:0: [sdb] tag#14 access beyond end of device
Dec 21 00:25:14 Sugo kernel: sd 1:0:0:0: [sdb] tag#15 access beyond end of device
Dec 21 00:25:14 Sugo kernel: sd 1:0:0:0: [sdb] tag#16 access beyond end of device
Dec 21 00:25:14 Sugo kernel: sd 1:0:0:0: [sdb] tag#17 access beyond end of device
Dec 21 00:25:14 Sugo kernel: XFS (sdb1): Filesystem has been shut down due to log error (0x2).
Dec 21 00:25:14 Sugo kernel: sd 1:0:0:0: [sdb] tag#18 access beyond end of device
Dec 21 00:25:14 Sugo kernel: XFS (sdb1): Please unmount the filesystem and rectify the problem(s).
Dec 21 00:25:14 Sugo kernel: sdb1: writeback error on inode 137, offset 171966464, sector 3997952
Dec 21 00:25:14 Sugo kernel: sdb1: writeback error on inode 137, offset 180355072, sector 4005552
Dec 21 00:25:14 Sugo kernel: sdb1: writeback error on inode 137, offset 188743680, sector 4030720
Dec 21 00:25:14 Sugo kernel: sdb1: writeback error on inode 137, offset 197132288, sector 4041984
Dec 21 00:25:14 Sugo kernel: sdb1: writeback error on inode 137, offset 201326592, sector 4044992
Dec 21 00:25:14 Sugo kernel: XFS (sdb1): log I/O error -5
Dec 21 00:25:14 Sugo kernel: XFS (sdb1): log I/O error -5
Dec 21 00:25:14 Sugo kernel: XFS (sdb1): log I/O error -5
Dec 21 00:25:14 Sugo kernel: XFS (sdb1): log I/O error -5

 

[DataCollector]

Die Meldungen sind nicht so ganz meine Welt, aber einige lassen auf Probleme mit der Festplatte, der Verbuindung oder dem Kontroller vermuten.
Ich weiß nicht ob ata1.00 ein Kontroller, einer seiner Ports oder eine Festplatte sein soll. Aber ich vermute mal ein Kontroller, da die Festplatte ja eher sd 1:0:0:0: [sdb] heißt.

 

"link is slow to respond, please be patient (ready=0)" = ein Befehl (vorheriger Hardreset?), der gesendet wurde, brauchte ungewöhnlich lange um erledigt/quittiert zu werden

 

"found unknown device (class 0)" = Da scheint ein Device (Festplatte? (wieder)gefunden zu sein, welche nicht mit den bekannten Geräten übereinstimmt.
...

 

"limiting SATA link speed to 3.0 Gbps" = es wird versucht die geschwindigkeit der SATA Verbindung von sonst üblichen 6Gbps auf die Hälfte zu reduzieren. Das kann Kommunikationsprobleme zwischen Kontrolel rund Festplatte mindern (geringere Anforderungen an die Verbindung).
Danach aber das gleiche Fehlerbild: Hardreset...unknown device....softreset....

 

"reset failed, giving up" = Das System hat aufgegeben mit dem Device auf die üblichen Wege eine normale Kommunikation aufzubauen

 

"disable device" = nun wird versucht das Gerät (oder nur ein Port auf dem Kontroller?) zu ignorieren, damit es keine Störungen verursacht

{Hier wird es schwammig, weil ich die exakte Bezeichnung unter Linux/slackware/unraid nicht kenne:}
Danach wird aber sdb mehrfach angesprochen und es werden Fehler (IOError für die jeweils angesprochenen Sektoren/Blöcke) gemeldet.
- Entweder kann unraid über den Kontroller die Platte nicht mehr erreichen (weil Kontroller disabled wurde)
- oder die Festplatte antwortet nur mit Fehlern, weil die Kommunikation nicht mehr fehlerfrei funktioniert
- oder unraid interpretiert alle abgesendeten Befehle als fehlerhaft quittiert, weil eben keine brauchbare Antwort mehr kommt.

 

"XFS (sdb1): log I/O error -5" = Dann entscheidet xfs (sdb1), daß hier ein errorlevel erreicht ist, der wohl kritisch ist (-5)
In Folge wird erkannt/gemeldet, daß das Device (festplatte sdb) nicht mehr die volle Kapazität von 31251759104, sondern nur noch 0 aufweist.

 

"sd 1:0:0:0: [sdb] tag#14 access beyond end of device" = Wenn also die Festplatte nur noch 0 Blöcke groß ist, ist es logisch, daß alle Zugriffe auf irgendwelche Blöcke hinter "0" zu weit hinten liegen.

 

"XFS (sdb1): Filesystem has been shut down due to log error (0x2)." = hier hat xfs nun komplett aufgegeben, weil es unlogisch ist, Blöcke anzusprechen , die es laut neuer Größenangabe gar nicht geben kann.

 

"sdb1: writeback error on inode 137, offset 171966464, sector 3997952" = Deshalb können diese Sektoren aus dem Chache nicht meh auf diese Festplatte zurückgeschrieben werden.
...
Naja, danach meldet xfs eben weiter: daß es hier einen kritischen Fehler gibt "XFS (sdb1): log I/O error -5"

 

 

Ich kann Dir nicht sagen, was genau Dein Problem hier ist, aber ich vermute der SATA Kontroller(Port)  hat erst Kommunikationsprobleme mit der Festplatte bekommen, dann die Geschwindigkeit reduziert um das Problem zu mindern, das hat keinen Erfolg gebracht und danach hat der Port/Kontroller aufgegeben.

In Folge hat unraid und das benutze Dateisystem xfs eben auch mitbekommen, daß da etwas nicht erfolgreich abläuft und im Endeffeklt auch von Softwareseite her 'abgeschaltet'.

 

Nun stellen sich einige Frage: welche Hardware ist hier beteiligt?

SATA Kontroller? USB Kontroller? SATA Kabel? USB Kabel? USB Bridgechip in einem externen USB/SATA Gehäuse? Welche Festplatte (gebraucht, neu, SMR)?

Wenn Du die beteiligten Komponenten bitte genauer benennen könntest (Modelle/Typenbezeichnungen/Art der Komponente). wäre das vielleicht noch hilfreich bei einer Aussage.

 

Ich bin irgendwie stark irritiert, dass ein Kontroller mit SATA Funktion hier als ata device bezeichnet wird.

Bei mir werden SATA Kontroller meist eher
   Serial bus controller
oder 
   SATA controller
bezeichnet.

Deswegen hege ich eine Vermutung, daß Du hier vielelicht ein Hotswap oder gar USB Konstrukt für Deine Sandisk SSD nutzt?

 

P.S.: Ich hoffe Du hast den Hinweis mit dem Backup von vor ca. 1 Jahr ernst genommen.

P.P.S: Vielleicht solltest Du diese SSD nicht mehr im Array betreiben oder Sich vielleicht sogar damit anfreunden, daß die vielleicht selber ein internes Problem hat. (ausgiebig unabhängig testen und ggf. aussortieren. Aktuell sind 4TB Festplatten oder auch SSD ja nicht mehr so teuer, wie damals.

P.P.P.S.: Ich schätze der Beubau ist nun fertig?

Edited December 21, 2023 by DataCollector

[Smolo]

Sehr ausführliche Antwort erstmal besten Dank hierfür.

 

Zur Hardware es handelt sich hier um eine 16TB HDD und nicht die SSD aus dem ursprünglichen Problemfall. Ich tippe mittlerweile auch auf ein Hardware Problem bin aber etwas überfragt. 

 

- Kabel kann ich mir nicht so recht vorstellen hatte ich nie Probleme mit

- Netzteil könnte ich mir am ehesten noch vorstellen das des zu wenig Dunst hat?!

- Defektes Mainboard / Controller wäre natürlich nen Totalschaden das kann ich mir aber auch weniger vorstellen.

 

Hotswap wäre mal eine Idee zum deaktivieren.

Kann jemand anderes was bezüglich ATA / SATA Meldung im Log sagen und ob das in Ordnung ist?

 

Bezüglich Bau immer noch mitten drin statt nur dabei aber so langsam biegen wir auf die Ziellinie ein ist halt derb wenn man alles selbst macht und das Objekt bissel größer ist