vdisk Read-only file system vdisk

frank80 · January 29, 2023

Hallo liebes Forum,

ich brauche mal eure Hilfe.

Fix Common Problems hatte mir gestern eine rote Fehlermeldung angezeigt.

Unable to write to disk1

Ich glaube, es handelt sich um 2 vdisk Dateien.

root@unraid:/mnt/user/06_Backup/11_ProxmoxBackupServer/Debian# ls -lh
total 4.0K
-rwxrwxrwx 1 nobody users 1.0T Feb 27  2022 vdisk2.img*
-----------
root@unraid:/mnt/user/06_Backup/11_ProxmoxBackupServer/PBS# ls -lh
total 337G
-rwxrwxrwx 1 root users 1.0T Jan 26 01:50 vdisk2.img*

Die VM´s habe ich gesichert und die vdisks könnte man löschen.

Kann mir jemand sagen, wie ich das Problem lösen kann?

Gruß Frank

mgutt · January 29, 2023

Nun ist sie denn voll oder kaputt oder was?!

Wenn die Dateien gelöscht werden können, warum löschst du sie dann nicht?!

Und warum ist deine Vdisk 1TB groß?!?!

frank80 · January 29, 2023

Hallo mgutt,

Voll auf keinen Fall, ich habe noch über 6 TB frei.

root@unraid:~# df -h
Filesystem      Size  Used Avail Use% Mounted on
rootfs           16G  1.1G   15G   7% /
tmpfs            32M  848K   32M   3% /run
/dev/sda1        29G  3.7G   25G  13% /boot
overlay          16G  1.1G   15G   7% /lib/firmware
overlay          16G  1.1G   15G   7% /lib/modules
devtmpfs        8.0M     0  8.0M   0% /dev
tmpfs            16G     0   16G   0% /dev/shm
cgroup_root     8.0M     0  8.0M   0% /sys/fs/cgroup
tmpfs           128M  684K  128M   1% /var/log
tmpfs           1.0M     0  1.0M   0% /mnt/disks
tmpfs           1.0M     0  1.0M   0% /mnt/remotes
tmpfs           1.0M     0  1.0M   0% /mnt/rootshare
/dev/md1         15T  8.1T  6.5T  56% /mnt/disk1
/dev/nvme0n1p1  932G   67G  865G   8% /mnt/cache
/dev/sdb1       472G   86G  380G  19% /mnt/vm
shfs             15T  8.1T  6.5T  56% /mnt/user0
shfs             15T  8.1T  6.5T  56% /mnt/user
/dev/sdg1       932G  158G  774G  17% /mnt/disks/PBS-Backup
/dev/loop2       30G   17G   13G  57% /var/lib/docker
/dev/loop3      1.0G  5.0M  904M   1% /etc/libvirt
tmpfs           3.2G     0  3.2G   0% /run/user/0
root@unraid:~#

Löschen würde ich gerne, die vdisk´s sind halt Read-only.

root@unraid:/mnt/user/06_Backup# rm -r 11_ProxmoxBackupServer
rm: cannot remove '11_ProxmoxBackupServer/Debian/vdisk2.img': Read-only file system
rm: cannot remove '11_ProxmoxBackupServer/PBS/vdisk2.img': Read-only file system
root@unraid:/mnt/user/06_Backup#

1 hour ago, mgutt said:

Und warum ist deine Vdisk 1TB groß?!?!

Ich habe eine VM mit Proxmox Backup Server für meine Proxmox VE Server.

Da meine PVE`s auch je 1 TB haben und ich noch genug TB´s habe, warum nicht?

Gruß Frank

mgutt · January 29, 2023

19 minutes ago, frank80 said:

Löschen würde ich gerne, die vdisk´s sind halt Read-only.

Dann ist vermutlich das Dateisystem hinüber. Klick mal auf das Disk Icon. Dann zeigt er die Logs zu der Disk an oder halt Tools > Syslog nach BTRFS Fehlern suchen.

Jedenfalls wäre der erste Schritt ein Backup zu machen. Dann auf die Disk klicken und eine Reparatur versuchen (scrub).

Ist dir der Server mal abgeschmiert / hart ausgeschaltet? BTRFS ist da was empfindlich.

frank80 · January 30, 2023

Hallo mgutt,

20 hours ago, mgutt said:

Dann ist vermutlich das Dateisystem hinüber

Das befürchte ich auch 😩

Hier das Log

Spoiler

Jan 29 13:24:30 unraid kernel: ata4: SATA max UDMA/133 abar m2048@0x51535000 port 0x51535280 irq 128
Jan 29 13:24:30 unraid kernel: ata4: SATA link up 6.0 Gbps (SStatus 133 SControl 300)
Jan 29 13:24:30 unraid kernel: ata4.00: ATA-10: TOSHIBA MG08ACA16TE, 0102, max UDMA/133
Jan 29 13:24:30 unraid kernel: ata4.00: 31251759104 sectors, multi 16: LBA48 NCQ (depth 32), AA
Jan 29 13:24:30 unraid kernel: ata4.00: Features: NCQ-prio
Jan 29 13:24:30 unraid kernel: ata4.00: configured for UDMA/133
Jan 29 13:24:30 unraid kernel: sd 4:0:0:0: [sde] 31251759104 512-byte logical blocks: (16.0 TB/14.6 TiB)
Jan 29 13:24:30 unraid kernel: sd 4:0:0:0: [sde] 4096-byte physical blocks
Jan 29 13:24:30 unraid kernel: sd 4:0:0:0: [sde] Write Protect is off
Jan 29 13:24:30 unraid kernel: sd 4:0:0:0: [sde] Mode Sense: 00 3a 00 00
Jan 29 13:24:30 unraid kernel: sd 4:0:0:0: [sde] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
Jan 29 13:24:30 unraid kernel: sd 4:0:0:0: [sde] Preferred minimum I/O size 4096 bytes
Jan 29 13:24:30 unraid kernel: sde: sde1
Jan 29 13:24:30 unraid kernel: sd 4:0:0:0: [sde] Attached SCSI disk
Jan 29 13:24:30 unraid kernel: BTRFS: device fsid 0c6db0b0-7bd0-48bd-890b-a9aab341325f devid 1 transid 203797 /dev/sde1 scanned by udevd (687)
Jan 29 13:26:43 unraid emhttpd: TOSHIBA_MG08ACA16TE_91T0A2J8FVGG (sde) 512 31251759104
Jan 29 13:26:43 unraid kernel: mdcmd (2): import 1 sde 64 15625879500 0 TOSHIBA_MG08ACA16TE_91T0A2J8FVGG
Jan 29 13:26:43 unraid kernel: md: import disk1: (sde) TOSHIBA_MG08ACA16TE_91T0A2J8FVGG size: 15625879500
Jan 29 13:26:43 unraid emhttpd: read SMART /dev/sde
Jan 29 13:44:42 unraid emhttpd: spinning down /dev/sde
Jan 29 13:57:01 unraid emhttpd: read SMART /dev/sde
Jan 29 14:12:14 unraid emhttpd: spinning down /dev/sde
Jan 29 14:23:30 unraid emhttpd: read SMART /dev/sde
Jan 29 14:38:31 unraid emhttpd: spinning down /dev/sde
Jan 29 15:00:01 unraid emhttpd: read SMART /dev/sde
Jan 29 15:16:02 unraid emhttpd: spinning down /dev/sde
Jan 29 15:33:06 unraid emhttpd: read SMART /dev/sde
Jan 29 15:48:07 unraid emhttpd: spinning down /dev/sde
Jan 29 17:04:32 unraid emhttpd: read SMART /dev/sde
Jan 29 17:29:50 unraid emhttpd: spinning down /dev/sde
Jan 29 20:25:00 unraid emhttpd: read SMART /dev/sde
Jan 29 20:40:13 unraid emhttpd: spinning down /dev/sde
Jan 29 23:30:26 unraid emhttpd: read SMART /dev/sde
Jan 29 23:45:41 unraid emhttpd: spinning down /dev/sde
Jan 30 00:31:23 unraid emhttpd: read SMART /dev/sde
Jan 30 00:46:24 unraid emhttpd: spinning down /dev/sde
Jan 30 07:45:52 unraid emhttpd: read SMART /dev/sde
Jan 30 08:11:56 unraid emhttpd: spinning down /dev/sde
Jan 30 11:40:00 unraid emhttpd: read SMART /dev/sde
Jan 30 11:55:01 unraid emhttpd: spinning down /dev/sde
Jan 30 14:40:01 unraid emhttpd: read SMART /dev/sde
Jan 30 14:55:02 unraid emhttpd: spinning down /dev/sde
Jan 30 19:27:57 unraid emhttpd: read SMART /dev/sde
Jan 30 19:43:11 unraid emhttpd: spinning down /dev/sde
Jan 30 19:53:18 unraid emhttpd: read SMART /dev/sde
Jan 30 20:15:11 unraid emhttpd: spinning down /dev/sde
Jan 30 20:18:06 unraid emhttpd: read SMART /dev/sde

** Press ANY KEY to close this window **

20 hours ago, mgutt said:

Jedenfalls wäre der erste Schritt ein Backup zu machen. Dann auf die Disk klicken und eine Reparatur versuchen (scrub).

Ein Backup habe ich gemacht.

Der scrub aus der GUI bringt keine Fehler, aber irgendwie glaube ich nicht das er funktioniert, weil er nach dem klick eigentlich auch schon wieder fertig ist.

UUID:             0c6db0b0-7bd0-48bd-890b-a9aab341325f
Scrub started:    Mon Jan 30 20:22:01 2023
Status:           aborted
Duration:         0:00:00
Total to scrub:   8.06TiB
Rate:             0.00B/s
Error summary:    no errors found

20 hours ago, mgutt said:

Ist dir der Server mal abgeschmiert / hart ausgeschaltet? BTRFS ist da was empfindlich.

Ja, mir ist auch aufgefallen, dass unraid sich meistens beim Backup auf meine Unraid-Backupserver mit deinem Rsync-Script oder beim Backup auf den PBS verabschiedet.

mgutt · January 30, 2023

34 minutes ago, frank80 said:

weil er nach dem klick eigentlich auch schon wieder fertig ist.

Ja da steht ja auch aborted. Komisch.

Nach dem scrub irgendwas in Tools > syslog?

frank80 · January 30, 2023

ich habe nur diesen Eintrag

Jan 30 21:25:10 unraid  ool www[5434]: /usr/local/emhttp/plugins/dynamix/scripts/btrfs_scrub 'start' '/mnt/disk1' ''

frank80 · February 6, 2023

Hallo zusammen,

ein kurzes Update.

Leider geht aktuell nicht mehr viel. Ich habe noch einmal eine Rsync-Sicherung gestartet, nach ca. 5 Std. war unraid nicht mehr erreichbar und ich musste den Rechner hart neu starten.

Als unraid wieder hochgefahren war, hat der Parity Check begonnen, was ebenfalls dazu geführt hat, dass unraid nach ein paar Stunden nicht mehr erreichbar war und ich wieder hart neu starten musste.

Was mir ebenfalls aufgefallen ist, es waren nicht nur die 2 vdisks, sondern mehrere Dateien die Read-Only sind.

So, heute ist meine neue HDD gekommen (brauchte sowieso eine), wie würdet ihr jetzt am besten vorgehen?

Array stop > HDD Defekt raus > Array start > Array stop > HDD neu rein > Array start ?

Gruß Frank

Edited February 6, 2023 by frank80

cz13 · February 6, 2023

Hab das Procedere noch nie machen müssen, falls der Fall dann mal eintritt würde ich mich an die Doku halten

https://wiki.unraid.net/Manual/Storage_Management#Replacing_failed.2Fdisabled_disk.28s.29

frank80 · February 6, 2023

Hallo cz13,

danke für den Link!!

Das Rebuild läuft und ich habe mich für das "Normal replacement" mit der Option 7 entschieden.

Gruß und danke

Frank

frank80 · February 7, 2023

Hallo zusammen,

so, hier ein ernüchterndes Update... 🙈

Das Rebuild ist fertig und ich habe unraid neu gestartet, nach ca. 10 Min. hatte ich die ersten Benachrichtigungen.

Die Fehler kamen in Dauerschleife bei Zugriff auf die Daten..

Feb  7 19:02:38 unraid kernel: BTRFS critical (device md1: state EA): unable to find logical 9455870400099729408 length 4096
Feb  7 19:02:38 unraid kernel: BTRFS critical (device md1: state EA): unable to find logical 9455870400099729408 length 16384
Feb  7 19:02:38 unraid kernel: BTRFS critical (device md1: state EA): unable to find logical 9455870400099729408 length 4096
Feb  7 19:02:38 unraid kernel: BTRFS critical (device md1: state EA): unable to find logical 9455870400099729408 length 16384
Feb  7 19:02:38 unraid kernel: BTRFS critical (device md1: state EA): unable to find logical 9455870400099729408 length 4096
Feb  7 19:02:38 unraid kernel: BTRFS critical (device md1: state EA): unable to find logical 9455870400099729408 length 16384

Fix Common Problems

Feb  7 19:08:06 unraid root: Fix Common Problems: Error: Unable to write to disk1

Was kann ich jetzt noch machen?

Gruß Frank

mgutt · February 7, 2023

2 hours ago, frank80 said:

Das Rebuild ist fertig

Meinst du Rebuild oder Check? Kein Mensch kann dich dazu zwingen den Check durchlaufen zu lassen. Das ist eben eine Vorsichtsmaßnahme von unRAID, wenn der Server nicht sauber heruntergefahren wurde.

2 hours ago, frank80 said:

Die Fehler kamen in Dauerschleife bei Zugriff auf die Daten..

Erweiterten SMART Test versuchen? SMART Daten prüfen? Ich würde aber vermutlich die Disk direkt ausbauen und gegen eine neue ersetzen. Danach kann man die Reparatur / Analyse ja als über UD gemountete Disk versuchen.

Es bringt ja nichts eine kaputte Disk weiter im Array zu lassen. Die ist entweder physisch kaputt oder irgendwas ganz grob mit dem Dateisystem hinüber.

Ich würde dann auch keinen Rebuild machen, sondern mit Tools > New Config das Array wie zuvor zuweisen, nur eben mit der neuen Disk 1 und dann die Parität neu aufbauen lassen. Danach die kaputte Disk per btrfs restore Richtung Disk 1 wiederherstellen. Mit einem klassischen Rebuild mit Disk Tausch stellt man sonst evtl einfach nur das kaputte Dateisystem wieder her.

frank80 · February 7, 2023

Hallo mgutt,

ich habe die „defekte“ HDD durch eine neue identische HDD ersetzt.

Hier bin ich nach der Anleitung aus dem Link von cz13 inkl. Punkt 7 vorgegangen.

Spoiler

To replace a failed disk or disks:

1. Stop the array.

2. Power down the unit.

3. Replace the failed disk(s) with a new one(s).

4. Power up the unit.

5. Assign the replacement disk(s) using the Unraid webGui.

6. Click the checkbox that says Yes I want to do this

7. (optional) Tick the box to start in Maintenance mode. If you start the array in Maintenance mode you will need to press the Sync button to trigger the rebuild. The advantage of doing this in Maintenance mode is that nothing else can write to the array while the rebuild is running which maximises speed. The disadvantage is that you cannot use the array in the meantime and until you return to normal mode cannot see what the contents of the disk being rebuilt will look like.

8. Click Start.to initiate the rebuild process.and the system will reconstruct the contents of the emulated didk(s) onto the new disk(s) and, if the new disk(s) is/are bigger, expand the file system.

1 hour ago, mgutt said:

Mit einem klassischen Rebuild mit Disk Tausch stellt man sonst evtl einfach nur das kaputte Dateisystem wieder her.

Ich vermute, dass genau das passiert ist.

Die ausgebaute HDD habe ich einmal testweise per USB an meine Synology DS gestöpselt.

Hier kann ich auf alle Daten zugreifen und auch die vdiks löschen, die in unraid auf Read-Only standen.

Gruß Frank

mgutt · February 7, 2023

5 minutes ago, frank80 said:

Die ausgebaute HDD habe ich einmal testweise per USB an meine Synology DS gestöpselt.

Hier kann ich auf alle Daten zugreifen und auch die vdiks löschen, die in unraid auf Read-Only standen.

Und in Unraid, wenn du sie da über USB mountest?

Und wie verhält sich der Zugriff nun nach dem Rebuild der neuen Disk?

frank80 · February 7, 2023

7 minutes ago, mgutt said:

Und in Unraid, wenn du sie da über USB mountest?

Das versuche ich morgen einmal.

7 minutes ago, mgutt said:

Und wie verhält sich der Zugriff nun nach dem Rebuild der neuen Disk?

Es hat keinen Unterschied gemacht.

Es ist als wäre die „defekte“ HDD im Array. Wie du weiter oben im Post auch schreibst, habe ich wieder ein defektes Dateisystem.

Edited February 7, 2023 by frank80

mgutt · February 7, 2023

Nun gibt es zwei Möglichkeiten:

a) weil der Rebuild den selben kaputten Zustand wiederhergestellt hat

b) weil die SATA Buchse / das Kabel defekt ist

Hast du ein Backup von den Daten der Disk? Dann könnte man einfach das machen:

- Screenshot von der Disk Übersicht machen

- Array stoppen

- Tools > New Config > Pools behalten

- Mit Unassigned Devices Plugin die Partition von der neuen kaputten Disk entfernen

- Disks wieder ins Array packen und starten, formatieren, usw

Wenn es kein Backup gibt, könnte man vom Prinzip das selbe machen und die alte Disk mounten und dann von der alten auf die neu formatierte kopieren.

Du solltest aber zu Anfang mal deinen RAM checken. Nicht dass der das Problem verursacht. Eventuell auch mit dem Preclear Plugin die Disk nullen und verifizieren, bevor du sie ins Array packst.

frank80 · February 8, 2023

Hallo,

Ok.

Dann gehe ich jetzt Mal der Reihe nach.

Memtest habe ich heute morgen gestartet, dann schauen wir heute Abend mal was er spricht.

SATA Kabel sind bestellt und kommen morgen.

Gruß und danke

Frank

Edited February 8, 2023 by frank80

frank80 · February 8, 2023

Hallo,

den Memtest habe ich nach über 9 Std. beendet und er brachte keine Fehler.

Die „defekte“ HDD habe ich per USB an unraid angeschlossen, kann sie aber nicht mounten.

Feb  8 20:56:57 unraid kernel: BTRFS warning: duplicate device /dev/sdi1 devid 1 generation 203841 scanned by mount (16657)
Feb  8 20:57:00 unraid unassigned.devices: Mount of 'sdi1' failed: 'mount: /mnt/disks/91T0A2J8FVGG: mount(2) system call failed: File exists.        dmesg(1) may have more information after failed mount system call. '

Morgen tausche ich das SATA-Kabel.

Gruß Frank

frank80 · February 10, 2023

Hallo,

neue Kabel sind angeschlossen.

Das habe bisher gemacht;

On 2/8/2023 at 12:31 AM, mgutt said:

- Screenshot von der Disk Übersicht machen

- Array stoppen

- Tools > New Config > Pools behalten

- Mit Unassigned Devices Plugin die Partition von der neuen kaputten Disk entfernen

- Disks wieder ins Array packen und starten, formatieren, usw

Den Parity-Sync habe ich abgebrochen, weil ich die Daten der alten HDD wieder auf die Disk1 kopieren wollte, kann die HDD aber nicht mounten.

Feb 10 17:01:54 unraid kernel: BTRFS error (device sdg1): unrecognized or unsupported super flag: 34359738368
Feb 10 17:01:54 unraid kernel: BTRFS error (device sdg1): dev_item UUID does not match metadata fsid: b1766b0c-5746-4d3f-a867-6ecb982ee7ba != 0c6db0b0-7bd0-48bd                                                                             -890b-a9aab341325f
Feb 10 17:01:54 unraid kernel: BTRFS error (device sdg1): superblock contains fatal errors
Feb 10 17:01:54 unraid kernel: BTRFS error (device sdg1): open_ctree failed
Feb 10 17:01:57 unraid unassigned.devices: Mount of 'sdg1' failed: 'mount: /mnt/disks/91T0A2J8FVGG: wrong fs type, bad option, bad superblock on /dev/sdg1, miss                                                                             ing codepage or helper program, or other error.        dmesg(1) may have more information after failed mount system call. '
Feb 10 17:01:57 unraid unassigned.devices: Partition '91T0A2J8FVGG' cannot be mounted.
Feb 10 17:03:12 unraid kernel: /dev/sdg1/: Can't open blockdev
Feb 10 17:04:00 unraid kernel: BTRFS error (device sdg1): unrecognized or unsupported super flag: 34359738368
Feb 10 17:04:00 unraid kernel: BTRFS error (device sdg1): dev_item UUID does not match metadata fsid: b1766b0c-5746-4d3f-a867-6ecb982ee7ba != 0c6db0b0-7bd0-48bd                                                                             -890b-a9aab341325f

Jetzt habe ich meine BackupHDD im Wechselrahmen und würde so vorgehen;

rsync -avP /mnt/disks/BackupHDD/ /mnt/disk1/

Die Backups habe ich so erstellt;

rsync -avP --exclude-from=/boot/config/exclude.txt /mnt/user/ /mnt/disks/BackupHDD/

Ist das OK?

mgutt · February 10, 2023

12 minutes ago, frank80 said:
rsync -avP /mnt/disks/BackupHDD/ /mnt/disk1/

Dadurch wird der Ordner BackupHDD in disk1 erstellt. Normal lässt man beim Ziel den / weg:

rsync -avP /mnt/disks/BackupHDD/ /mnt/disk1

Aber du hast jetzt ein Problem. Du hast /mnt/user/ gesichert. Du hast also den Inhalt von disk1 UND cache gesichert.

Oder hast du keinen Cache?

Wenn nein, sollte es so richtig sein:

rsync -avP /mnt/disks/BackupHDD/user/ /mnt/disk1

Check das bitte vorher. Ansonsten hast du nachher doppelte Dateien

frank80 · February 10, 2023

4 minutes ago, mgutt said:

rsync -avP /mnt/disks/BackupHDD/user/ /mnt/disk1

Ich kopiere aus user, dann sollte es so reichen;

rsync -avP /mnt/disks/BackupHDD/ /mnt/disk1

Cache ist dabei. 🙈

Was mache ich jetzt am besten?

Edited February 10, 2023 by frank80

mgutt · February 10, 2023

Oh nein. Warum ^^

Waren nur bestimmte Ordner auf disk1? Oder auch appdata? Also die Frage ist, ob man vielleicht nur einzelne Ordner auf disk1 wiederherstellt.

frank80 · February 10, 2023

29 minutes ago, mgutt said:

Oh nein. Warum ^^

Ich dachte, ich habe mir wieder ein Ei gelegt.

Auf dem Backup sind außer meinen eigenen Ordnern (+ Daten-Ordner im Bild) noch diese...

Cache im zweiten Bild

Edited February 10, 2023 by frank80

mgutt · February 10, 2023

29 minutes ago, frank80 said:

Auf dem Backup sind außer meinen eigenen Ordnern (+ Daten-Ordner im Bild) noch diese...

Cache im zweiten Bild

Wir probieren erstmal abzugleichen:

rsync -a --itemize-changes --dry-run /mnt/disks/BackupHDD/user/appdata/ /mnt/cache/appdata

Optimal wäre keine Ausgabe. Dann wäre der Ordner mit dem Backup identisch.

frank80 · February 10, 2023

3 minutes ago, mgutt said:

rsync -a --itemize-changes --dry-run /mnt/disks/BackupHDD/user/appdata/ /mnt/cache/appdata

leider nicht identisch, ich weiß jetzt wie viele, aber >9999 Zeilen

vdisk Read-only file system vdisk

Recommended Posts

Link to comment

Top Posters In This Topic

Popular Days

Top Posters In This Topic

Popular Days

Popular Posts

mgutt

frank80

Posted Images

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Join the conversation