BTRFS raid1 degraded beim Boot

[Judge]

Hallo zusammen,

ich habe auf meinem Raspberry Pi 4 Raspberry OS, welches ja nahezu ausschließlich Debian ist. Daher hoffe ich hier eine passende Antwort zu finden, nachdem man mir im Raspberry Forum nicht helfen konnte.

Der Pi bootet ohne SD Karte direkt von USB. An einem der USB3-Ports habe ich einen aktiven USB3-Hub und daran wiederum 2 500GB USB-Festplatten angeschlossen. Das Partitionslayout hiervon sieht wie folgt aus:

Code: Alles auswählen

Disklabel type: dos
Disk identifier: 0xf99a3312

Device     Boot  Start       End   Sectors   Size Id Type
/dev/sda1         8192    532479    524288   256M  c W95 FAT32 (LBA)
/dev/sda2       532480 976773167 976240688 465.5G 83 Linux

sda und sdb sind identisch partitioniert.

Mit sda2 und sdb2 habe ich ein raid1 btrfs Dateisystem erstellt:

Code: Alles auswählen

root@cloudpi:~# btrfs fi show
Label: 'rootfs'  uuid: 04f080b4-049f-40a6-8175-0b4bd0cf5109
	Total devices 2 FS bytes used 10.33GiB
	devid    2 size 465.51GiB used 12.03GiB path /dev/sda2
	devid    3 size 465.51GiB used 12.03GiB path /dev/sdb2

root@cloudpi:~# btrfs fi df /
Data, RAID1: total=11.00GiB, used=10.23GiB
System, RAID1: total=32.00MiB, used=16.00KiB
Metadata, RAID1: total=1.00GiB, used=102.50MiB
GlobalReserve, single: total=17.22MiB, used=0.00B
root@cloudpi:~#

In meiner fstab habe ich das wie folgt eingetragen:

Code: Alles auswählen

proc            /proc           proc    defaults          0       0
PARTUUID=1991f10c-01  /boot            vfat    defaults          0       2

UUID=04f080b4-049f-40a6-8175-0b4bd0cf5109  /               btrfs    defaults,device=PARTUUID=f99a3312-02,device=PARTUUID=1991f10c-02,compress  0       0

Ich habe zudem eine neue init-RamDisk mit den BTRFS modulen unter /boot/initramfs-btrfs.gz erstellt:

Code: Alles auswählen

# /etc/initramfs-tools/modules
btrfs
xor
zlib_deflate
raid6_pq
raid1

/boot/cmdline.txt habe ich wie folgt angepasst:

Code: Alles auswählen

console=serial0,115200 console=tty1 root=UUID=04f080b4-049f-40a6-8175-0b4bd0cf5109 rootfstype=btrfs elevator=deadline fsck.repair=no rootwait rootflags=degraded

An /boot/config.txt habe ich nur ein paar wenige Kleinigkeiten wie die RamDisk und program_usb_timeout angepasst:

Code: Alles auswählen

# For more options and information see
# http://rpf.io/configtxt
# Some settings may impact device functionality. See link above for details

initramfs initramfs-btrfs.gz

# uncomment if you get no picture on HDMI for a default "safe" mode
#hdmi_safe=1

# uncomment this if your display has a black border of unused pixels visible
# and your display can output without overscan
#disable_overscan=1

# uncomment the following to adjust overscan. Use positive numbers if console
# goes off screen, and negative if there is too much border
#overscan_left=16
#overscan_right=16
#overscan_top=16
#overscan_bottom=16

# uncomment to force a console size. By default it will be display's size minus
# overscan.
#framebuffer_width=1280
#framebuffer_height=720

# uncomment if hdmi display is not detected and composite is being output
#hdmi_force_hotplug=1

# uncomment to force a specific HDMI mode (this will force VGA)
#hdmi_group=1
#hdmi_mode=1

# uncomment to force a HDMI mode rather than DVI. This can make audio work in
# DMT (computer monitor) modes
#hdmi_drive=2

# uncomment to increase signal to HDMI, if you have interference, blanking, or
# no display
#config_hdmi_boost=4

# uncomment for composite PAL
#sdtv_mode=2

#uncomment to overclock the arm. 700 MHz is the default.
#arm_freq=800

# Uncomment some or all of these to enable the optional hardware interfaces
#dtparam=i2c_arm=on
#dtparam=i2s=on
#dtparam=spi=on

# Uncomment this to enable infrared communication.
#dtoverlay=gpio-ir,gpio_pin=17
#dtoverlay=gpio-ir-tx,gpio_pin=18

# Additional overlays and parameters are documented /boot/overlays/README

# Enable audio (loads snd_bcm2835)
dtparam=audio=on

[pi4]
# Enable DRM VC4 V3D driver on top of the dispmanx display stack
dtoverlay=vc4-fkms-v3d
max_framebuffers=2

[all]
#dtoverlay=vc4-fkms-v3d
gpu_mem=32
program_usb_timeout=1

Trotz all dieser Konfigurationen sieht mein BTRFS Dateisystem nach erfolgreichem Boot ("/" liegt ja sogar auf diesem Dateisystem) so aus:

Code: Alles auswählen

root@cloudpi:~# btrfs fi show
Label: 'rootfs'  uuid: 04f080b4-049f-40a6-8175-0b4bd0cf5109
	Total devices 2 FS bytes used 10.33GiB
	devid    2 size 465.51GiB used 14.06GiB path /dev/sda2
	devid    3 size 465.51GiB used 12.03GiB path /dev/sdb2

root@cloudpi:~# btrfs fi df /
Data, RAID1: total=11.00GiB, used=10.23GiB
Data, single: total=1.00GiB, used=2.61MiB
System, RAID1: total=32.00MiB, used=16.00KiB
System, single: total=32.00MiB, used=0.00B
Metadata, RAID1: total=1.00GiB, used=102.50MiB
Metadata, single: total=1.00GiB, used=0.00B
GlobalReserve, single: total=16.47MiB, used=0.00B
WARNING: Multiple block group profiles detected, see 'man btrfs(5)'.
WARNING:   Data: single, raid1
WARNING:   Metadata: single, raid1
WARNING:   System: single, raid1
root@cloudpi:~#

Hat irgendjemand eine gute Idee woran das liegen könnte?

Danke schonmal für die Hilfe!

[smutbert]

Wie hast du das btrfs-Dateisystem erstellt?
(Mir scheint du hast das btrfs zuerst nur auf einer Partition erstellt und später die zweite Partition hinzugefügt und dann den Daten- und Metadatenmodus auf raid1 geändert? Dann musst auch »btrfs balance« starten damit alles im neuen Modus geschrieben wird.)


Wieso hast du »rootflags=degraded« in den Kernelparametern drin?
(Mir ist aber ehrlich gesagt gefühlsmäßig ein über zwei über USB angeschlossene Festplatten verteiltes btrfs nicht ganz geheuer – dazu wäre mir usb etwas zu fehleranfällig.)

[Judge]

Ja, so ist es auch! Jedoch zeigt doch die erste Ausgabe von vor meinem Boot das alles gebalanced ist, oder nicht? (Bin noch nicht soooo firm mit btrfs).
BTRFS via 2x USB HDD ist natürlich nicht das rock-stable was man gerne hätte; auf dem Pi aber ja das beste was man machen kann wenn man viel Speicher für vertretbare Kosten haben will. Aber gerade hier dachte ich ist BTRFS das beste was man machen kann, da COW und RAID ja eigentlich recht unanfällig sein sollten ...

Das »rootflags=degraded« habe ich drin, da mein Gedanke folgender ist:
Entweder "sieht" der Pi beide Partitionen beim starten und bindet sie ein, oder er sieht eine davon NICHT und bleibt dann - degraded - im Pre-Boot hängen; was mich auch nicht viel nutzt.

[smutbert]

Ja, so ist es auch! Jedoch zeigt doch die erste Ausgabe von vor meinem Boot das alles gebalanced ist, oder nicht? [...]

Ah, die habe ich übersehen. Ja, da scheint alles im raid1-Modus gespeichert zu sein.

Laut manpage ist eine mögliche Ursache eine nicht abgeschlossene Konvertierung mit btrfs-balance, aber dagegen spricht die Ausgabe, die ich übersehen habe.

Meine andere Idee ist, dass das Dateisystem degraded mit nur einem Gerät gemountet und trotzdem, zwangsweise im single-Modus, beschrieben worden ist. Ich habe versucht das nachzustellen und habe es so mit einem sauber angelegten raid1 zu einem ähnlichen Ergebnis gebracht:

Code: Alles auswählen

# btrfs fi df /mnt/tmp
Data, RAID1: total=1.00GiB, used=684.80MiB
Data, single: total=832.00MiB, used=0.00B
System, RAID1: total=8.00MiB, used=16.00KiB
System, single: total=32.00MiB, used=0.00B
Metadata, RAID1: total=256.00MiB, used=1.00MiB
Metadata, single: total=256.00MiB, used=0.00B
GlobalReserve, single: total=3.25MiB, used=0.00B
WARNING: Multiple block group profiles detected, see 'man btrfs(5)'.
WARNING:   Data: single, raid1
WARNING:   Metadata: single, raid1
WARNING:   System: single, raid1

Das kann meiner Auffassung nach nur mit der degraded-Mountoption passieren, wenn beim Mounten nur eines der beiden beteiligten Geräte verfügbar ist. (Kann gut sein, dass USB beim Erkennen langsam genug ist, dass das die Ursache ist.)
Zumindest eine mögliche Lösung wäre imho also das Weglassen von rootflags=degraded.

Vielleicht (!) könnte eine andere Alternative Lösung darin bestehen das Dateisystem beim Booten im read-only Modus zu mounten und dann im fstab-Eintrag erst im rw-Modus zu mounten (da sollte dein aktueller fstab-Eintrag passen).

Code: Alles auswählen

onsole=serial0,115200 console=tty1 root=UUID=04f080b4-049f-40a6-8175-0b4bd0cf5109 rootfstype=btrfs elevator=deadline fsck.repair=no rootwait ro rootflags=degraded

(habe ein ro vor den rootflags eingefügt, aber weiß nicht ob das gewünschten Effekt erzielt)


Unangenehm und zumindest denkbar wäre es allerdings, wenn du schon öfter als einmal so mit degraded gebootet hättest und dabei nicht jedes Mal das gleiche Gerät gemountet worden wäre. In dem Fall wären die Daten, durch die Schreibvorgänge auf die beiden einzelnen Geräte im single-Modus wahrscheinlich schon inkonsistent.

[Judge]

Spät, ich weiß; aber um das hier mal abzuschließen: Leider passiert mit dem "ro" Parameter weiterhin dasselbe. Ohne das "rootflags=degraded" bekommt das FS keine Chance zu degraden, da es einfach nicht weiter bootet; auch nicht, wenn das fehlende USB-Device wenige Sekunden später erkannt wird.
Ich habe "rootwait=10" probiert. Das hat jedoch ebenfalls keinen Sinn, da das root-FS - aus Kernel-Sicht - ja gefunden wird; nur leider: nicht vollständig. Das bleibt aber erst im Btrfs-internen Code hängen und ich konnte keine Möglichkeit finden hier anders zu warten, bis alle gefunden werden konnten.
Ich habe ebenfalls versucht das "langsamere" USB Device als root=PARTUUID=... anzugeben, jedoch klappte das auch nicht zuverlässig.

Ich habe letzten Endes aufgegeben und ein Script gebaut, was nach einem Reboot das FS wieder fixt. Ist extrem blöd, aber hoffentlich sichert es so zumindest gegen defekte Hardware zur Laufzeit ab.

[biber33]

Wenn auf Festplatten beim Booten gewartet werden soll, dann ist die Kerneloption rootdelay=XX die richtige. Damit wartet der Kenel XX Sekunden bevor er überhaupt versucht das rootfs zu mounten. Mein BTRFS Raid 1 zwischen 1 SATA und 1 USB Platte funktioniert damit problemlos.