Schlagwort-Archive: LVM

BitBastelei #568 – bcachefs: Der neue Dateisystem-Alleskönner für Linux

BitBastelei #568 - bcachefs: Der neue Dateisystem-Alleskönner für Linux

(380 MB) 00:35:52

2023-12-03 11:00 🛈

Im Speicherumfeld gibt es einige All-in-one-Dateisysteme, welche viele Funktionen wie RAID, Volume Management, Snapshots, verteilen auf unterschiedlich schnelle Geräte, Kompression u.v.A. ineinander Vereinen. Am bekanntesten sind ZFS, welches jedoch lizenztechnisch schwierig ist, und BTRFS, welches – zumindest bei mir – nicht grade für seine Datensicherheit bekannt ist. Bcachefs verspricht diese Probleme zu lösen und noch mehr Funktion zu unterstützen. Ende 2023/Anfang 2024 soll das System das erste mal im stabilen Kernel verfügbar sein, also schauen wir mal wie man das nutzt.

Inhalt

  • 00:00 Dateisystemtheorie
  • 02:01 Copy-on-Write & Snapshots
  • 03:21 RAID & LVM
  • 06:09 bcachefs
  • 08:28 Voraussetzungen
  • 11:11 Partition fomatieren
  • 12:11 Verschlüsselung
  • 13:15 Kompression
  • 15:51 Attribute: Konfiguration pro Datei/Ordner
  • 16:59 Striping („RAID0“)
  • 18:27 Replicas („RAID1/RAID10“)
  • 20:28 Erasure Coding („RAID5/RAID6“)
  • 21:20 Tiered Storage / Caching
  • 28:21 Sysfs-Schnittstelle
  • 30:11 Subvolumes und Snapshots
  • 32:36 Ausblick und Fazit

Links zum Thema

Sonstige Hinweise

  • Den Grammatikfehler im Beispieltext hat ChatGPT ganz alleine hinbekommen… Oo
  • 14:46 Die Level unterscheiden sich je nach Algorithmus. Für zstd sollten laut Anleitung -7 bis 22 zulässig sein

Transparenz

Es ist Open Source und kostenlos. Was erwartet ihr hier? 😉

Linux: Partitionen innerhalb einer Image-Datei/LV mounten

Bisher speicherte ein Windows-System seine Datensicherung per CIFS (aka Samba) auf einer Linux-basierten NAS. Das Konzept ist dabei schon etwas älter – die Windows-Software unterstützte bei der Einrichtung weder Kompression noch Deduplizierung, sodass hier das ZFS-Dateisystem der Linux-Kiste einiges an Platz einsparen konnte. Inzwischen ist die Windows-Software gewachsen: Kompression und Deduplizierung werden bereits vorab durchgeführt, dafür machten die vielen neuen Funktionen immer häufiger Probleme mit CIFS. Kaputte Locks, schlechte Performance, Verbindungsabbrüche – alles lässt sich recht genau auf die Kombination aus dem Server und CIFS zurückführen. Während eine „normale“ Kopie unter Linux mit etwa 100MB/s von statten geht schafft der Server nur 4MB/s. Andere Protokolle sind schneller, andere Windows-Server haben ebenfalls keine Probleme. Inzwischen sind ohnehin neue Platten fällig – Zeit hier gegenzusteuern.

Die Speicherung soll weiterhin auf der Linux-Kiste erfolgen – dort ist die Sicherung und Verwaltung deutlich zuverlässiger und flexibler. Andererseits habe ich keine Lust auf CIFS-Fehlersuche, also lassen wir es einfach weg – die Lösung: iSCSI. Der Windows-Server greift direkt auf den rohen Datenträger des Linux-Systems zu. Da wie erwähnt keine Linux-seitige Kompression stattfinden muss wird diese einfach per LVM verwaltet und ist über den Kernel-iSCSI-Server exportiert. Das Anlegen verläuft ohne Probleme, müssen nur noch die Daten rüben. Mit 4MB/s. Bei fast 4TB. Mit 5 Tagen Restzeit. Nope.

Also, fassen wir nochmal zusammen: Sowohl der alte als auch der neue Datenbestand liegen auf dem selben Linux-System. Warum nicht einfach da kopieren? NTFS-Schreiben unter Linux ist zwar nicht schnell, aber die 4MB/s-Marke sollte zu schaffen sein. Problem: Auf dem LVM-LV hat Windows automatisch eine GPT-Partitionstabelle angelegt, sie lässt sich also nicht direkt unter Linux mounten.

Um trotzdem an das NTFS-System zu kommen müssen wir erst mal wissen wo die passende Partiton beginnt. Hier kommt parted zum Einsatz, welcher auch GPT-Partitionstabellen unterstützt. Da wir die Angaben in Byte, nicht den üblichen Sektoren, benötigen muss die Anzeige erst ungeschaltet werden.

[root@nas ~]# parted /dev/speicher2/windows9
GNU Parted 3.2
/dev/dm-1 wird verwendet
Willkommen zu GNU Parted! Rufen Sie "help" auf, um eine Liste der verfügbaren Befehle zu erhalten.
(parted) unit B
(parted) print
Modell: Linux device-mapper (linear) (dm)
Festplatte  /dev/dm-1:  4178147540992B
Sektorgröße (logisch/physisch): 512B/512B
Partitionstabelle: gpt
Disk-Flags:

Nummer  Anfang      Ende            Größe           Dateisystem  Name                          Flags
 1      17408B      134235135B      134217728B                   Microsoft reserved partition  msftres
 2      135266304B  4178146492415B  4178011226112B  ntfs         Basic data partition          msftdata
(parted) quit

Wie wir sehen wurden auf dem LVM-LV durch Windows zwei Partitionen angelegt: Die Erste enthält Managementdaten, die Zweite ist unsere eigentliche NTFS-Datenpartition. Letztere beginnt bei 135266304 Byte – genau diesen Bereich müssen wir auf dem Datenträger also überspringen um auf das NTFS-Dateisystem zugreifen zu können. Also legen wir uns ein passendes Loop-Device an. Da ich bereits ein anderes Device aktiv habe nutze ich loop2 – generell ist die Zahl wählbar.

[root@nas ~]# losetup -o 135266304 /dev/loop2 /dev/speicher2/windows9
[root@nas ~]# mount -t ntfs-3g /dev/loop2 /mnt/test/
[root@nas ~]# mount | grep test
/dev/loop2 on /mnt/test type fuseblk (rw,nosuid,nodev,relatime,user_id=0,group_id=0,allow_other,blksize=4096)
[root@nas ~]# df -h test/
Dateisystem    Größe Benutzt Verf. Verw% Eingehängt auf
/dev/loop2      3,8T    604G  3,3T   16% /mnt/test

Passt doch, schon haben wir unter Linux nativen Zugriff auf das Device. Das Kopieren läuft nun mit 90MB/s – nicht ganz die bestmögliche Geschwindigkeit, für NTFS über fuse aber kein Schlechter wert – und etwas schneller als die 4MB/s der Windows-Kiste.

Linux LVM: „Hängende“ Snapshots entfernen

Was ein Murks: Einer meiner Server brauchte dank Problem des Festplattentreibers einen Neustart. Nach dem Boot fiel mir auf, dass im LVM-System einige alte Snapshots von Systemtests liegen geblieben sind. Schnell mal aufräumen – oder auch nicht, denn dummerweise wollte LVM da nicht mitspielen. Erst mal eine kleine Übersicht des Systems:

root@rescue:~# pvs
PV VG Fmt Attr PSize PFree
/dev/md2 storage lvm2 a-- 2.70t 1.57t
root@rescue:~# vgs
VG #PV #LV #SN Attr VSize VFree
storage 1 32 9 wz--n- 2.70t 1.57t
root@rescue:~# lvs
LV VG Attr LSize Pool Origin Data% Move Log Copy% Convert
[...]
test-www4-boot storage swi-a-s- 512.00m www4-boot 0.10
test-www4-data storage swi-a-s- 70.00g www4-data 38.39
test-www4-root storage swi-a-s- 20.00g www4-root 63.09
test2-www4-boot storage swi-a-s- 512.00m www4-boot 0.10
test2-www4-data storage swi-a-s- 70.00g www4-data 37.31
test2-www4-root storage swi-a-s- 20.00g www4-root 59.58
www4-boot storage owi-a-s- 512.00m
www4-data storage owi-a-s- 73.24g
www4-root storage owi-a-s- 20.00g
[...]

Man sieht die mit „test“ beginnenden Snapshots welche entfernt werden sollen. Üblicherweise reicht hier ein lvremove welches folgende Ausgabe brachte:

Do you really want to remove active logical volume test-www4-root? [y/n]: y
/sbin/dmeventd: stat failed: No such file or directory
/sbin/dmeventd: stat failed: No such file or directory
Unable to deactivate open storage-test--www4--root-cow (253:2)
Failed to resume test-www4-root.
libdevmapper exiting with 3 device(s) still suspended.

Ab diesem Punkt ist die LVM-Verwaltung faktisch tot. Kommandos wie z.B. lvs hängen sich auf und geben keine Ausgabe. Erst nach einem Reboot ist die Verwaltung wieder möglich, dann taucht der soeben gelöschte test-www4-root wieder auf, ist allerdings kein Snapshot mehr und lässt sich nun auch fehlerfrei entfernen. Keine schöne Lösung, denn ich habe viele Snapshots und dazu eine Abneigung gegen Reboots. Mit strace findet man im hängenden Zustand folgendes:

ioctl(3, DM_TABLE_STATUS, 0x81b5a40) = 0
stat64("/dev/storage/www4-root", {st_mode=S_IFBLK|S_ISVTX|0660, st_rdev=makedev(253, 1), ...}) = 0
open("/dev/storage/www4-root", O_RDONLY|O_DIRECT|O_LARGEFILE|O_NOATIME) = 4
fstat64(4, {st_mode=S_IFBLK|S_ISVTX|0660, st_rdev=makedev(253, 1), ...}) = 0
open("/dev/storage/www4-root", O_RDONLY|O_LARGEFILE) = 5
ioctl(5, BLKGETSIZE64, 0xffcc33a8) = 0
close(5) = 0
close(4) = 0
open("/dev/storage/www4-root", O_RDONLY|O_LARGEFILE) = 4
ioctl(4, BLKGETSIZE64, 0xffcc3378) = 0
close(4) = 0
stat64("/dev/storage/www4-root", {st_mode=S_IFBLK|S_ISVTX|0660, st_rdev=makedev(253, 1), ...}) = 0
open("/dev/storage/www4-root", O_RDONLY|O_DIRECT|O_LARGEFILE|O_NOATIME) = 4
fstat64(4, {st_mode=S_IFBLK|S_ISVTX|0660, st_rdev=makedev(253, 1), ...}) = 0
ioctl(4, BLKBSZGET, 0x8174458) = 0
_llseek(4, 21474770944, [21474770944], SEEK_SET) = 0
read(4,

Der Auslöser scheint also die Snapshotquelle zu sein, nicht der Snapshot selbst. Eine Suche brachte mich zur Debian-ML auf der das Problem beschieben wird – dankenswerterweise funktionierte der Workarround auch in meiner Situation:

– Der lvremove-Befehl wird in einer Shell abgesetzt und hängt sich auf
– Auf einer zweiten Shell setzt man die Snapshotquelle manuell mit folgenden Befehl wieder in Gang: „dmsetup resume /dev/storage/www4.root“
– Die erste Shell reagiert wieder, der Snapshot sollte verschwunden sein
– Ggf. zurückgebliebene Laufwerksleichen werden mit „dmsetup remove /dev/storage/xxx“ entfernt