BTRFS-Fehler schreibt Logs voll - Synology nicht mehr erreichbar

[adahmen]

Mache ich.
Im Moment lasse ich den Speichertest nochmal ohne zusätzliches RAM laufen. Nicht das am Ende der interne Speicher nicht okay ist.

Das weitere Problem ist, dass das System unerträglich langsam ist. Wie gesagt habe ich diverse Docker-Container mit einigem Speicherhunger laufen. Docker war selbst nach mehr als 30 Minuten noch nicht gestartet :-(

Speicher ist bestellt und soll Dienstag kommen.

 

[synfor]

Lass das mit Docker, solange du keinen zusätzlichen RAM drin hast.

 

[adahmen]

Ich muss erstmal dazu kommen Docker stoppen zu können

 

[adahmen]

Kann man Docker bzw. den Container Manager während des Starts irgendwie stoppen?

Und der erneute MemoryTest ohne Erweiterung war okay:

2023-09-23T19:04:04+02:00 diskstation720 findhostd[11670]: util_fhost.c:1195 Memtest passed!

 

[adahmen]

Ich gehe davon aus, dass dein Filesystem einfach einen irreparablen Schaden hat, evtl. verursacht durch inkompatiblen RAM. Da hilft auch ein Austausch des RAM nichts mehr. Lass mal, ohne den Zusatz-RAM, eine Datenbereinigung laufen. Und wenn die das auch nicht bereinigen kann, dann setz die Kiste neu auf.

Wo genau startet man die Datenbereinigung?

 

[Benares]

Hier, im Speicher-Manager, beim jeweilen Speicherpool

 

[adahmen]

Alles klar, Danke! - mache ich aber erst, wenn der Speicher da ist und die Synology wieder "bedienbar" ist.

 

[Benares]

Kannst du auch jetzt schon machen, damit das System evtl. schon "sauber" ist, bevor der neue Speicher kommt.
Aber ich sehe da ziemlich schwarz, wenn das Filesystem irreparabel ist.

 

[geimist]

Kann man Docker bzw. den Container Manager während des Starts irgendwie stoppen?

@DSM7.2:
synopkg stop ContainerManager
@ < DSM7.2:
synopkg stop Docker

Das weitere Problem ist, dass das System unerträglich langsam ist.

Das erklärt aus meiner Sicht:

Die SMR-Platte (WD40EFAX) sollte besser auch ersetzt werden.

Wie sieht denn die Festplattenausnutzung aus?
Du merkst es halt jetzt besonders, weil dein Cache nicht aktiv ist (und warum du überhaupt den Cache so wertvoll findest).

 

[synfor]

Das Problem ist da weniger die SMR-Platte, sondern eher der fehlende RAM -> Swapping.

 

[adahmen]

Das sehe ich auch so. Container Manager konnte ich stoppen und nun ist die 720+ wieder normal bedienbar.
Aktuell laufen noch die täglichen Sicherungen.
Danach versuche ich die Datenbereinigung.

 

[adahmen]

Kurze Frage: Bekommt man bei der Datenbereinigung irgendeinen Hinweis, ob etwas "repariert" bzw. etwas gefunden wurde?

Aktuell läuft die Datenbereinigung auf einer der beiden Platten und steht bei knapp 40%.

 

[maxblank]

Nur die Beendigung des Vorgangs, zumindest ist es bei mir mit den Standardeinstellungen so oder ich hatte noch keinen Fehler.
Alternativ mal die Logs durchgehen.

https://kb.synology.com/de-de/DSM/help/LogCenter/logcenter_search?version=7

 

[adahmen]

So, die Datenbereinigung ist durch. Keine Fehlermeldung oder sonstige Hinweise.
Auch sind alle Backups in dieser Nacht ohne Probleme gelaufen. Zudem sind sowohl die Speicherpools und die Volumes in Status "in Ordnung".
Im DSM würde man keine Fehler bemerken. Auch keine Hinweise im Protokoll-Center.

Dennoch sind Fehler in /var/log/messages zu finden:

2023-09-25T07:09:23+02:00 diskstation720 kernel: [130035.435175] BTRFS warning (device dm-5): corrupt leaf fixed, bad key order, block=4293908774912, root=7, slot=74
2023-09-25T07:09:23+02:00 diskstation720 kernel: [130035.446670] BTRFS warning (device dm-5): corrupt leaf fixed, bad key order, block=4293908774912, root=7, slot=75
2023-09-25T07:09:23+02:00 diskstation720 kernel: [130035.458149] BTRFS warning (device dm-5): corrupt leaf fixed, bad key order, block=4293908774912, root=7, slot=76
2023-09-25T07:09:23+02:00 diskstation720 kernel: [130035.469630] BTRFS warning (device dm-5): corrupt leaf fixed, bad key order, block=4293908774912, root=7, slot=77
2023-09-25T07:09:23+02:00 diskstation720 kernel: [130035.481112] BTRFS warning (device dm-5): corrupt leaf fixed, bad key order, block=4293908774912, root=7, slot=78
2023-09-25T07:09:23+02:00 diskstation720 kernel: [130035.492592] BTRFS warning (device dm-5): corrupt leaf fixed, bad key order, block=4293908774912, root=7, slot=79
2023-09-25T07:09:23+02:00 diskstation720 kernel: [130035.504064] BTRFS warning (device dm-5): corrupt leaf fixed, bad key order, block=4293908774912, root=7, slot=80
2023-09-25T07:09:23+02:00 diskstation720 kernel: [130035.515541] BTRFS warning (device dm-5): corrupt leaf fixed, bad key order, block=4293908774912, root=7, slot=81
2023-09-25T07:09:23+02:00 diskstation720 kernel: [130035.527017] BTRFS warning (device dm-5): corrupt leaf fixed, bad key order, block=4293908774912, root=7, slot=82
2023-09-25T07:09:23+02:00 diskstation720 kernel: [130035.538493] BTRFS warning (device dm-5): corrupt leaf fixed, bad key order, block=4293908774912, root=7, slot=83
2023-09-25T07:09:23+02:00 diskstation720 kernel: [130035.549976] BTRFS warning (device dm-5): corrupt leaf fixed, bad key order, block=4293908774912, root=7, slot=84
2023-09-25T07:09:23+02:00 diskstation720 kernel: [130035.561451] BTRFS warning (device dm-5): corrupt leaf fixed, bad key order, block=4293908774912, root=7, slot=85
2023-09-25T07:09:23+02:00 diskstation720 kernel: [130035.572928] BTRFS warning (device dm-5): corrupt leaf fixed, bad key order, block=4293908774912, root=7, slot=86
2023-09-25T07:09:23+02:00 diskstation720 kernel: [130035.584401] BTRFS warning (device dm-5): corrupt leaf fixed, bad key order, block=4293908774912, root=7, slot=87
2023-09-25T07:09:24+02:00 diskstation720 kernel: [130035.595877] BTRFS warning (device dm-5): corrupt leaf fixed, bad key order, block=4293908774912, root=7, slot=88
2023-09-25T07:09:24+02:00 diskstation720 kernel: [130035.607352] BTRFS warning (device dm-5): corrupt leaf fixed, bad key order, block=4293908774912, root=7, slot=89
2023-09-25T07:09:24+02:00 diskstation720 kernel: [130035.618828] BTRFS warning (device dm-5): corrupt leaf fixed, bad key order, block=4293908774912, root=7, slot=90
2023-09-25T07:09:24+02:00 diskstation720 kernel: [130035.630303] BTRFS warning (device dm-5): corrupt leaf fixed, bad key order, block=4293908774912, root=7, slot=91
2023-09-25T07:09:24+02:00 diskstation720 kernel: [130035.641787] BTRFS warning (device dm-5): corrupt leaf fixed, bad key order, block=4293908774912, root=7, slot=92
2023-09-25T07:09:24+02:00 diskstation720 kernel: [130035.653263] BTRFS critical (device dm-5): corrupt leaf: root=7 block=4293908774912 slot=91, csum end range (2953625489408) goes beyond the start range (2953625485312) of the next csum item
2023-09-25T07:09:24+02:00 diskstation720 kernel: [130035.672438] BTRFS error (device dm-5): cannot fix 4293908774912, record in meta_err

Die letzte Zeile mit dem BTRFS error taucht nicht immer auf. Der Rest wiederholt sich in unregelmäßigen Abständen.

Kann man rausfinden, welches device gemeint ist?

 

[Fusion]

cat /proc/mdstat sollte dir zeigen was sich hinter dev/md5 verbirgt.

 

[adahmen]

Ich glaube das klappt so nicht - denn ist ist nicht md5, sondern dm-5

admin@diskstation720:~$ cat /proc/mdstat
Personalities : [raid1]
md3 : active raid1 sata2p3[0]
      5855700544 blocks super 1.2 [1/1] [U]
     
md2 : active raid1 sata1p3[0]
      3902196544 blocks super 1.2 [1/1] [U]
     
md1 : active raid1 sata1p2[0] sata2p2[1]
      2097088 blocks [2/2] [UU]
     
md0 : active raid1 sata1p1[0] sata2p1[1]
      2490176 blocks [2/2] [UU]
     
unused devices: <none>

 

[adahmen]

So, ich glaube ich bin ein wenig weiter gekommen (nach ein bisschen Suche) - würde mich aber über Feedback freuen.

Über folgenden Befehl bekomme ich eine Übersicht der BTRFS "devices":

sudo btrfs fi show

Label: '2021.09.24-10:26:18 v41890'  uuid: 3fd61fb7-7b0d-45d0-9439-91f7394da96e
    Total devices 1 FS bytes used 3.68TiB
    devid    1 size 5.45TiB used 3.72TiB path /dev/mapper/cachedev_0

Label: '2021.09.16-16:30:32 v41890'  uuid: 2db3f6fc-5623-47de-917d-9928693254d3
    Total devices 1 FS bytes used 2.52TiB
    devid    1 size 3.63TiB used 3.51TiB path /dev/mapper/cachedev_1

Und mit diesem Befehl gibt es eine Zuordnung der dm-x devices:

sudo dmsetup info /dev/dm-5
Name:              cachedev_1
State:             ACTIVE
Read Ahead:        4096
Tables present:    LIVE
Open count:        1
Event number:      0
Major, minor:      248, 5
Number of targets: 1

Das würde doch bedeuten, dass dm-5 das device cachedev_1 ist. Und cachedev_1 ist die 3,6 TB Platte.

Und das ist bei mir Speicherpool 1 mit Volume 1.



Ist es eigentlich möglich, nur die eine Platte neu zu initiatlisieren? Sind nicht auf der ersten Platte die ganzen Pakete abgelegt?
Was würdet Ihr mir vorschlagen, den Fehler zu bereinigen?
Oder kann man es noch auf der Kommandozeile versuchen?

 

[Benares]

Öhm, blick's grad nicht. Hast du (NVME-)SSDs als Cache?

 

[adahmen]

Ja, aber die sind gerade deaktiviert - also nicht als Cache aktiv.
Das war der erste Hinweis hier in diesem Thread.

 

[adahmen]

Oder hat das doch noch was mit dem damaligen Cache zu tun?

Und mir ist da noch was eingefallen: Nachdem ich den SSD-Cache eingebaut habe, hatten wir einen Elektriker im Haus, der fälschlicherweise den Strom ausgeschaltet hat :-(
Das könnte wohl die Ursache für das Problem sein, oder?

Und wenn es "nur" der Cache ist - kann man diesen nicht "löschen" oder einfach neu anlegen?