DSM 7.1 DS 918+ und 920+ nicht mehr erreichbar (lokal) - "Prüfsummen stimmen nicht überein"

[ds214se]

Beide LAN-Ports funktionieren für sich alleine einwandfrei - aber danke Dir auch für diesen guten Hinweis!

 

[Ronny1978]

@ctrlaltdelete
Deine Erfahrung spricht eindeutig für Dich - es gibt Probleme mit dem LAN-Bonding, denn seit ca. 10 Minuten ist der Zugriff auf die DS 920+ wieder unmöglich. Also werde ich nochmal die Netzwerkeinstellungen etc. zurücksetzen und bis auf weiteres auf LAG/ LAN-Bonding verzichten.

Mit dem Update 4 hat es sehr wahrscheinlich nichts zu tun, aber wenigstens habe ich einiges dazugelernt und werde die Datenkonsistenz im Blick behalten.

Das hatte ich auch mal mit meiner DS918+. Es lag hier definitiv am Switch, wahrscheinlich auch in Kombination mit der Fritzbox. Seit ich auf OpnSense und Unifi Komponenten umgestellt habe, habe ich keinerlei Probleme mehr mit LAGG an meiner DS918+.

 

[ds214se]

@Ronny1978
Den TL-SG1024DE Switch mit LAG und dem entsprechenden LAN1+2 Bonding auf meinen beiden größeren DS habe ich seit ca. 1 Jahr problemlos in Betrieb. Ich werde nochmal die Kabel austauschen und die LAG-Einstellungen ändern - wenn ich mehr Zeit habe. Denn es ist doch immer sehr mühselig, an so vielen verschiedenen Stellen im DSM die Netzwerkeinstellungen wieder hinzubiegen, nachdem man einen Reset machen musste, weil man keinen Zugriff mehr auf die DS hat wegen Problemen mit dem LAG/Bond.

So habe ich jetzt ein anderes, neues Phänomen, was vermutlich im Zusammenhang mit den Netzwerk-Änderungen zusammenhängt: Ich kann die SMB-Einstellungen nicht mehr ändern. Aber dazu mache ich einen separaten Thread auf.

 

[ds214se]

Aus einem anderen Thread zitiere ich mich einmal selbst:

Hallo zusammen!

Der Thread ist zwar schon älter, aber aus aktuellem Anlass hänge ich meine Beobachtung hier an:

Mit meinem TP-Link SG1024DE (4.20) Switch (auf dem ich natürlich LAG für 2 Ports aktivierte), ließ sich die dynamische Link Aggregation zuerst nicht auf meiner DS920+ aktivieren (rote Fehlermeldung, dass es nicht möglich sei, ohne weitere Erklärung). Erst nachdem ich die statische Link Aggregation (Balance XOR) aktiviert hatte (was problemlos ging), konnte ich die dynamische Link Aggregation auf der DS aktivieren. Ich weiß nicht, woran das lag, aber es geht jetzt (wieder).

 

[Synchrotron]

Weshalb überhaupt der Bond ? Gibt es dafür einen nachvollziehbaren Einsatzfall ? Oder muss halt in jede LAN-Buchse ein Stecker, weil sie wäre ja sonst leer ?

 

[ds214se]

@Synchrotron
Danke für Deine berechtigte Frage. Der Grund ist, dass auf meine NAS 4 PCs zeitweise gleichzeitig zugreifen und Dateien hin- und herschieben. Ich habe nicht nachgemessen, ob/welchen Geschwindigkeitsunterschied es gibt, wenn ich nur ein LAN des NAS belege im Vgl. zum Bond. Dazu fehlt mir die Zeit.

 

[Benares]

Oder muss halt in jede LAN-Buchse ein Stecker, weil sie wäre ja sonst leer ?

Bei mir muss auch in jede Lan-Buchse ein LAN-Kabel, in jeden Speicher-Slot ein RAM-Riegel und in jedes Festplattenfach ne Platte.
Nein, nicht ernst gemeint , aber der war gut.

 

[ds214se]

Für jeden Topf sein Deckel!

 

[ds214se]

Zurück zum eigentlichen Thema "Prüfsummen stimmen nicht überein":



Die letzte Warnung kam nach einer manuell gestarteten Datenbereinigung von Speicherpool 1 (RAID 10 mit Datenschutz) und betrifft eine Datei, zu der bereits zuvor eine solche Warnung vorlag. Ich verstehe das so, dass diese eine Datei (oberste Zeile im Screenshot) immer noch ein Checksum-Problem hat. Was mache ich nun damit?

Zu den anderen Warnungen, andere Dateien betreffend, kam jetzt keine weitere Warnung. Verstehe ich das richtig, dass bei diesen anderen Dateien kein Problem mehr vorliegt? Wurden die (Btrfs) "geheilt"?

Vor allem: Um welche Dateien handelt es sich denn hier überhaupt? Das sind ja keine Nutzerdaten, also irgendwelche Dokumente auf SMB-Shares o.ä., sondern sie scheinen alle irgendwie etwas mit Synology Drive zu tun zu haben - abgesehen von der zweitobersten Zeile (wo ich den Host-Namen unkenntlich gemacht habe).

xxxxx@xxxxx:/volume1/@synologydrive/@sync/repo/3/3/t$ ls -al
total 45392
drwxr-xr-x 1 root root       56 Feb 22 07:18 .
-rw-r--r-- 1 root root     8192 Feb 22 07:18 ._
drwxr-xr-x 1 root root      128 Mar  1 15:23 ..
-rw-r--r-- 1 root root  4476928 Feb 22 07:15 .2
-rw-r--r-- 1 root root    16384 Feb 22 07:15 .3
-rw-r--r-- 1 root root        0 Feb 22 07:15 .4
-rw-r--r-- 1 root root        0 Feb 22 07:15 .5
-rw-r--r-- 1 root root        0 Feb 22 07:15 .6
-rw-r--r-- 1 root root       52 Feb 22 07:15 .7
-rw-r--r-- 1 root root  5005312 Feb 22 07:15 .a
-rw-r--r-- 1 root root  5648384 Feb 22 07:15 .d
-rw-r--r-- 1 root root 30990336 Feb 22 07:16 .D
-rw-r--r-- 1 root root    32768 Feb 22 07:16 .E
-rw-r--r-- 1 root root    32768 Feb 22 07:16 .J
-rw-r--r-- 1 root root   173072 Feb 22 07:16 .L
-rw-r--r-- 1 root root    98912 Feb 22 07:16 .M

Die SMART-Werte aller 4 HDDs erscheinen übrigens unauffällig, ebenso für die 2 SDDs (RAID 1 mit Datenschutz). Alle Btrfs-Metadaten werden im SSD-Cache gespeichert. Der Datenträger-Schreibcache ist für alle 4 HDDs und die 2 SDDs deaktiviert. Die DS hängt an einer USV. Der durchgeführte Speichertest war unauffällig.

Habt Ihr einen Hinweis für mich, was es mit diesen Dateien auf sich hat und ob ich nun Platten austauschen muss?

Danke für Eure Hilfe!

 

[ctrlaltdelete]

Evtl. fehlerhafter SSD Cache?

 

[ds214se]

Bei normalen SMART-Werten?

Und was könnte ich bzgl. dieser Dateien tun? Mir ist nicht einmal klar, wofür die sind und ob die Dateien, bei denen jetzt keine Warnung mehr kommt, wieder ok sind.

 

[ds214se]

@ctrlaltdelete und andere Experten:

Heute erhielt ich nach einer manuell gestarteten Datenträgerbereinigung (wieder) eine Benachrichtigung bzgl. nicht übereinstimmender Prüfsummen (checksum mismatch). Seltsamerweise taucht im Protokoll nichts dazu auf. Die letzte Warnung diesbzgl. im Protokoll war am 12.03.2023 und zeigte dies:

Checksum mismatch on file [/volume1/@synologydrive/@sync/repo/3/3/t/.D].

Allerdings fand ich heute nach Abschluss der Datenträgerbereinigung dies in der Konsole:

2023-03-24T14:05:44+01:00 NAS kernel: [24377.837609] checksum error found by scrub at logical 1686926262272 on dev /dev/mapper/cachedev_0, mirror = 0, metadata = 0

Hast Du/habt Ihr eine Idee, worauf das hinweist?

Der Speichert-Test war ok, die SMART-Werte auch (sowohl von den HDDs, als auch von den SDDs).

Nochmals herzlichen Dank und Euch allen ein schönes Wochenende!

 

[ctrlaltdelete]

Hattest du denn den Cache mal gelöscht und neu aufgebaut?

 

[ds214se]

Ja, habe ich - ohne Fehlermeldungen.
Ist /dev/mapper/cachedev_0 SSD-Cache?

 

[Benares]

Ist /dev/mapper/cachedev_0 SSD-Cache?

Nein, meines Wissen nicht, zumindest nicht per se. Es ist nur ein Device, das den Cache ggf. nutzt, falls einer angelegt ist.