Seit geraumer Zeit habe ich scheinbar "Corruption Errors" auf meinen beiden Cache-Laufwerken.

Ich setze das momentan immer wieder mal wieder zurück, aber spätestens wenn ich Scrub drüber laufen lasse, dann erscheinen die Fehler wieder.

Wenn ich mir in den anhängenden Diagnosedateien die syslog.txt am Ende anschaue, so scheint es mir ein Problem mit MariaDB zu sein.

Bekomme ich diese Fehler irgendwie behoben? Wenn ja, wie? Was muss ich da tun?

VG und Danke vorab

Hylli

urs1-diagnostics-20260822-1804.zip

In Unraid unter Main → Cache-Pool → Scrub ist besonders interessant:

Corrected: ?

Uncorrectable: ?

Unverified: ?

Bei einem Btrfs-Pool mit zwei Laufwerken im RAID1-/Mirror-Profil kann Scrub eine beschädigte Kopie normalerweise von der intakten zweiten Kopie reparieren. Wenn dagegen Uncorrectable größer als 0 ist, gibt es für mindestens einige Blöcke keine gültige zweite Kopie mehr.

Hi,

ich habe von Anfang an immer die gleiche Anzahl an uncorrectable errors je Laufwerk. Aktuell sind es 56/56:

Error summary:    csum=112
  Corrected:      0
  Uncorrectable:  112
  Unverified:     0

Hylli

In deinen Diagnostics sieht man:

Der Cache-Pool besteht aus 2× NVMe im Btrfs RAID1.

Beim Scrub treten auf beiden NVMes dieselben logischen Fehlerbereiche auf.

Btrfs meldet ausdrücklich unable to fixup, also: keine der beiden RAID1-Kopien ist für diese Blöcke gültig.

Mindestens ein betroffener Bereich lässt sich eindeutig dieser Datei zuordnen:

/mnt/cache/appdata/mariadb/databases/edb696c2a7b3.err

Btrfs nennt dabei sogar denselben Inode:

inode 9878256

offset 6742016

length 4096

Die NVMes sehen außerdem nicht nach einem offensichtlichen Defekt aus

Die im Diagnostics-Paket enthaltenen SMART-Daten zeigen für beide WD-NVMes:

SMART overall-health: PASSED

Critical Warning: 0x00

Media and Data Integrity Errors: 0

Auch die Extended Self Tests wurden ohne Fehler abgeschlossen.

Hast du eine Sicherung von vor dem 17.08., die du verwenden könntest?

Wenn ja, würde ich den MariaDB-Container stoppen, das aktuell möglicherweise korrupte MariaDB-Verzeichnis zunächst auf ein USB-Laufwerk oder an einen anderen sicheren Ort wegkopieren und anschließend die ältere Sicherung zurückspielen.

Danach MariaDB wieder starten und prüfen, ob alles funktioniert. Anschließend einen erneuten Btrfs-Scrub durchführen.

Wenn der Scrub dann keine uncorrectable errors mehr meldet, war sehr wahrscheinlich nur dieser Datenbestand beschädigt.

Wichtig: Wenn die alte Sicherung dieselben beschädigten Blöcke bereits enthält, bleiben die Fehler natürlich bestehen. Deshalb ist eine Sicherung von deutlich vor dem ersten bekannten Auftreten ideal.

Ich würde außerdem nach dem Zurückspielen erst kurz prüfen, ob MariaDB/Nextcloud sauber läuft, und danach den Scrub starten.

und für die Zukunft das Thema btrfs überdenken.

es ist (leider) immer wieder ein Thema das btrfs im Bezug auf docker, Datenbanken, usw gerne Probleme verursacht.

da bringt ein redundanter pool wenig, wenn es raid1 sein muss, Wechsel zu zfs in Betracht ziehen oder bei Verzicht der Redundanz single drive xfs

(Backups nicht vergessen)

On 8/23/2026 at 7:49 AM, alturismo said:

und für die Zukunft das Thema btrfs überdenken.

es ist (leider) immer wieder ein Thema das btrfs im Bezug auf docker, Datenbanken, usw gerne Probleme verursacht.

da bringt ein redundanter pool wenig, wenn es raid1 sein muss, Wechsel zu zfs in Betracht ziehen oder bei Verzicht der Redundanz single drive xfs

(Backups nicht vergessen)

Kann ich nicht bestätigen mit btrfs (läuft bei mir auf 2 systemen seit langer zeit ohne probleme (ja auch mit datenbanken). man liest ja nichts von den systemen bei denen es ohne probleme läuft, nur von denen mit problemen. daraus würde ich den einsatz von btrfs im cache nicht überdenken (der faktor liegt wahrscheinlich bei 1000 zu 1), da das sogar die vorgabe von unraid ist. ;-)

Bei mir sieht's genauso aus, wie bei @dibux : bislang keine Probleme mit btrfs!

in meinen beiden unraid-Systemen werkelt auch jeweils ein btrfs-cache, einmal als RAID1 und einmal single

mein zusätzlicher 4TB Raid1 Pool läuft sogar auch auf btrfs

Aber es läuft einfach ohne Probleme ... bislang klopfaufholz

Ja, man liest hier mehr von Problemen mit btrfs, aber ich denke auch einfach weil es bei unraid Standard war/ist und wenn dann "mach mal neu als zfs" kommt, liegt es anschließend immer am "bösen btrfs", aber ist das wirklich so?

Auch zu zfs hat man hier schon von Problemen gelesen, da ist dann auch teilweise nichts mehr zu retten und es muss ein Backup restored werden. M.M.n. auch nicht besser, daher hab ich den Änderungs-Aufwand auch noch nicht betrieben.

Vielleicht sollte man mal eine Umfrage starten:

Wer nutz was? wer hatte schonmal Probleme mit filesystem xy? konnte es repariert werden? war format/restore notwendig? traten nach fs wechsel weitere Probleme auf?

Ist halt für die meisten sicher auch schwer zu beurteilen, ob die Probleme wirklich im Filesystem begründet sind, oder ob ein spezielles dafür ursächlich war oder vielleicht auch etwas ganz anderes. Wenn ich formatiere (egal welches fs) und ein lauffähiges Backup zurückspiele, läuft es so oder so immer erstmal wieder, egal auf welchem fs. (erinnert mich hier manchmal auch an Windows-Foren damals: am Ende hieß es dort eh immer "neu installieren" 😆).

6 hours ago, _alo_ said:

Ja, man liest hier mehr von Problemen mit btrfs, aber ich denke auch einfach weil es bei unraid Standard war/ist und wenn dann "mach mal neu als zfs" kommt, liegt es anschließend immer am "bösen btrfs", aber ist das wirklich so?

mir ist es persönlich 2x passiert, seither ist es für mich "ex", einmal (wegen eigen Dummheit) auch fatal ;)

und ja, natürlich ist es oft erstmals btrfs, aber man hört halt nach Umstellung nichts mehr ... daher sage ich persönlich klar ja, es liegt darsn ...

war ja vor "Docker Directory" noch häufiger im btrfs Image das sehr oft Docker Images corrupt gingen, nicht schlimm da schnell wieder erstellt, aber trotzdem ... Fehlersuche usw usw

Und auch ja, bei zfs hatten wir anfangs auch oft "destroy and new please", das hing aber eher an der Implementierung in Unraid, ist halt auch etwas komplexer und schnell mal "fail" 😬

ich nutze weder noch, immer nur single xfs und Backup, seither nie wieder auch nur ansatzweise ein Problem, Backup (bisher) nie gebraucht ...

btrfs zu anfällig meiner Erfahrung nach (und auch wie oft ich das gelesen hatte)

zfs total overhyped für mein homelab, daher auch nichts für mich

Schöne ist, wir haben die Wahl und es war auch nur ein Ratschlag meinerseits.

Es hat jetzt ein wenig gedauert, da ich mir die vergangenen Tage mal Gedanken gemacht habe.

Das Problem konnte ich leider nicht lösen, da ich mit dem Problem zu lange gewartet habe, und ich kein Backup ohne diesen Fehler hatte.

Mehrere Tatsachen bringen mich nun dazu, dass ich gerne UnRAID nochmals komplett neu aufsetzen möchte_

• Die Tatsache, dass ich den Fehler nicht los bekomme.

• Die Tatsache, dass ich über die letzten 5 Jahre sehr vieles getestet habe, und dadurch auch viel Datenmüll entstanden ist.

• Die Tatsache, dass UnRAID ja einige Fortschritte gemacht hat, wie z.B. Unterstützung ZFS oder Wechsel auf ein internes Boot-Laufwerk usw.

• ...

Nun würde ich gerne komplett neu starten, aber dabei meine bestehende Hardware erst einmal weiter nutzen wollen, naja u.a. auch der Speicherpreise wegen.

Bisher sieht es so aus:

• Mainboard: ASRock X570M Pro4

• CPU: AMD Ryzen 7 PRO 4750G

• RAM: 64 GiB DDR4 Multi-bit ECC

• 2x Western Digital WD_BLACK SN750 (WDS100T3X0C) M.2 NVMe SSD 1TB als Cache-Pool im RAID1

• 4x Western Digital Red 8TB (WD80EFZX) -> 1x Paritiy, 3x Daten

• 1x USB-Stick SanDisk Cruzer Blade als Bootlaufwerk

Falls ich auf ein internes Boot-Laufwerk wechseln wollte: Eine weitere M.2 SSD kann ich leider nicht mehr verbauen, lediglich eine 2,5" SATA SSD. (Der noch vorhandene M.2 2230 Anschluss, ist nur für WiFi gedacht!)

Ich habe mal alles wichtige für mich auf zwei externe Festplatten gesichert und möchte eigentlich nochmals von 0 starten, und dabei sinnvoll vorgehen.

Wie gehe ich das Thema am besten an?

VG

Hylli

38 minutes ago, hylli said:

Wie gehe ich das Thema am besten an?

naja, wenn wirklich alles auf "0" soll

1/ Lizenz Datei sichern vom Stick

2/ Stick neu erstellen

3/ Lizenz Datei in den /config Ordner auf dem neu erstellten Stick kopieren

4/ booten

5/ nach dem Start, Tools, internal boot Wizard starten

-- internal boot konfigurieren, dabei wird die nvme (oder raid1) formatiert, Vorschlag, nur die 16 GB für boot reservieren, dann kannst du den pool nutzen

6/ 4 x HDD ... halt formatieren wenn die auch platt gemacht werden sollen, sollte halt überlegt sein ob das Sinn macht

danach bist du bei "0" und kannst starten mit Backup der Daten einspielen usw.