Status von Btrfs 2023?

[heisenberg]

Hallo zusammen,

grundsätzlich finde ich ja Btrfs schon das Dateisystem der Wahl für freie Systeme der Zukunft. Insgesamt scheint mir Btrfs gemäß meiner Prioritäten zum aktuellen Zeitpunkt aber immer noch ungeeignet für einen Produktivbetrieb zu sein.

Status

Wenn ich mir dass hier anschaue ...

https://wiki.debian.org/Btrfs

... dann sieht mir das wie ein ziehmliches Schlachtfeld aus. Also man muss auf vieles achten, sonst hat man in vielen Situationen möglicherweise Datenverlust.

Wenn ich mir dann den aktuellen Status von Btrfs anschaue, hier ...

https://btrfs.readthedocs.io/en/latest/Status.html

... dann steht da auch noch häufig beim Thema Stabilität und einigen Funktionen "Mostly OK". Das ist jetzt auch irgendwie nicht ein Dateisystem, dass ich produktiv einsetzen möchte. Device Replace ist auf "Mostly OK" - Für ein Produktivsystem inakzeptabel. Kann natürlich auch sein, dass das einfach nur ehrlich ist und die Seltenheit des Auftretens von manchen Fehlern sehr gering ist und z. B. im Vergleich zu HW-RAID-Controllern dort auch existieren aber dort halt einfach unbekannt sind, weil nicht dokumentiert bzw. veröffentlicht.

Degraded RAID

Wenn ich ein Degraded RAID Array habe, also eine Platte ist z. B. ausgefallen, dann wünsche ich mir eine Anwendung derart, dass ich das System uneingeschränkt weiter betreiben kann. Mir ist natürlich klar, dass die Redundanz dann ggf. weg ist und wenn Datenfehler auftreten, dann sind die durch das RAID-Array selbst nicht mehr reparabel. Das ist für mich völlig in Ordnung so und mir wichtiger, als wenn ein Server ein oder mehrere Tage ausfällt.

In der Vergangeheit habe ich hier dazu gelesen, wenn man ein System mit einem Degraded-RAID betreibt, dann werden Blöcke im Format Single geschrieben. Wenn man daraufhin dann neu startet, dann erkennt Btrfs dass da verschiedene Formate verwendet werden (z. B. single + raid1) und setzt das Dateisystem unwiederruflich Read-only. Im Wiki-Beitrag hier Btrfs zu Btrfs steht, dass das ein "Bug" war, der behoben wurde. Meine Frage dazu ist, ob so ein Konzept noch irgendwie als normale Vorgehensweise umgesetzt wurde. Das wäre für mich ein absolutes NoGo.

Meine Erwartung ist da: Wenn ein RAID degraded ist, dann kann ich damit völlig normal weiter arbeiten. Dann ersetze ich die Platte irgendwann mal - nach 1 - x Tagen. Anschließend synchronisiert sich das alles wieder und somit ist der redundante Normalzustand wieder hergestellt.

Festplatten ersetzen

Wenn es um das Ersetzen von Festplatten geht, ist bei mir da noch eine große Unklarheit über den tatsächlichen Ablauf. Verstanden habe ich, dass Btrfs grundsätzlich und zusätzlich zu den vorhanden Festplatten immer die neue Festplatte dazu nimmt, den Ersetzungsvorgang durchführt und dann die alte Platte entfernt.

Das ist sehr sinnvoll das so zu tun, weil, wenn auf einer Platte ein Datenfehler auftritt, dann können die Daten immer noch von der zu evakuierenden Platte genommen werden, um Datenfehler zu vermeiden.

Manchmal ist das aber nicht möglich. Wenn z. B. ein System nur 4 Festplattenschächte hat und alle 4 sind belegt, dann muss man zwangsläufig eine Festplatte abklemmen, um die neue Festplatte anschließen zu können. Kann man das mit Btrfs auch irgendwie machen?

RAID-10

Ich habe nicht genau verstanden, wie Btrfs RAID-10 genau verwendet. Hier habe ich eine ganz gute Erklärung dazu gefunden:

Englisch: https://lore.kernel.org/linux-btrfs/87v ... sis.net/T/

Als wichtiges Element ist dort noch zu lesen, dass die RAID-Funktionalität von Btrfs nicht auf Blockdevices (z. B. /dev/sda) operiert, sondern auf Chunks. Chunks sind 1 GB grosse Datenblöcke, die dann gemäß des RAID-Levels auf den Blockdevices verteilt werden. Am besten in dem obigen Thread nachlesen für Details.

Last-but-not-least ist für mich RAID5/6 nice-to-have, also verzichtbar.

Viele Grüße,
heisenberg

[Tintom]

Möchtest du Erfahrungen speziell von Usern, die die RAID-Funktionen von btrfs verwenden? Oder möchtest du Erfahrungen von allen Usern, die btrfs verwenden? Oder ganz was anderes? Das wird aus deinem Beitrag nicht ganz klar.

[bluestar]

Insgesamt scheint mir Btrfs gemäß meiner Prioritäten zum aktuellen Zeitpunkt aber immer noch ungeeignet für einen Produktivbetrieb zu sein.

Ich muss mich deiner Einschätzung leider zu 100% anschließen, weder im Single Disk noch im RAID Betrieb hat sich Btrfs bei mir als reif für den Produktivbetrieb gezeigt. Ob Btrfs jemals an die heutige Reife von ZFS (aktuell 2.1.x) herankommt, da habe ich persönlich große Zweifel.

[heisenberg]

@Tintom:

Ich wäre in erster Linie dankbar für Stellungnahmen, Meinungen und weitere Erläuterungen zu den Themen, die ich konkret geschildert habe. Darüber hinaus interessiert mich noch der Einsatz von Btrfs im professionellen Umfeld im Bereich von sehr kleinen bis maximal mittleren Unternehmensgrößen.

[wanne]

Wenn ich ein Degraded RAID Array habe, also eine Platte ist z. B. ausgefallen, dann wünsche ich mir eine Anwendung derart, dass ich das System uneingeschränkt weiter betreiben kann. Mir ist natürlich klar, dass die Redundanz dann ggf. weg ist und wenn Datenfehler auftreten, dann sind die durch das RAID-Array selbst nicht mehr reparabel. […] Meine Erwartung ist da: Wenn ein RAID degraded ist, dann kann ich damit völlig normal weiter arbeiten.

Wenn du ein klassisches RAID willst, dass availibility und speed über integrity setzt nutze MD-RAID! Es war explizit nie das Ziel von btrfs das zu ersetzen. Beides ist teil der gleichen Software (dem Linux Kernel) und harmonisiert weil es vom gleichen Entwicklerteam gepflegt wird explizit problemlos zusammen. Du kannst wunderbar btrfs auf nem MD-RAID betreiben. (Im Gegensatz zu ZFS, dass in vielen Teilen (insbesondere Caching) eigenes Zeug macht.)


Der eigentliche Vorteil von btrfs ist eigentlich, dass es im Gegensatz zu Hardware-RAIDs und ZFS eben keine festen Array größen hast und so 99% der Aktionen die da nötig sind und die dann btfs kaputt schießen eben nicht brauchen.
Es gibt absolut keinen Grund, warum man sein Array im degraded zustand betreiben will.
Wenn eine platte ausfällt, kannst du einfach folgendes machen:
a) btrfs balance start -mconvert=dup -dconvert=single /mnt
Um das Array ohne eigenes Redundanzdevice weiter zu betreiben
oder sinnvoller
b) btrfs device remove missing
Um das Array um ein Device zu verkleinern und sobald die Ersatzplatte da ist, btrfs device add machen. – Das funktioniert natürlich nicht, wenn du ein RAID hast, dass aus lediglich 2 Platten besteht.
Mit letzterem schaffst du halt eine Datensicherheit, die ZFS und Konsorten niemals erreichen können. – Hast aber eben den Nachteil, dass das kurz dauert.

[heisenberg]

Es gibt absolut keinen Grund, warum man sein Array im degraded Zustand betreiben will.

a) Sprich bitte nur für Dich. Ich finde es für mich in meiner Umgebung - wie bereits geschrieben - grundsätzlich absolut akzeptabel für ein paar Tage ein Array degraded laufen zu lassen. Ist das grundsätzlich so, dass man danach das Btrfs kaputt gemacht hat, wenn man das tut?

Für den Worst-Case gibt's zusätzlich noch das Backup. Bisher habe ich mit meiner Strategie noch keine Ausfälle gehabt. Es ist für mich absolut in Ordnung, dass Du da höhere Ansprüche an Datenintegrität hast als ich.

b) Das heisst, wenn eine Platte bei Dir ausfällt und Du hast gerade keine Ersatzplatte auf Lager, dann schaltest Du den Server ab, bis eine Ersatzplatte da ist, fährst den Server dann wieder hoch und ersetzt dann die Platte? Oder betreibst das Ganze immer nur mit Hotspare? (Habe von Btrfs und Hotspare auch noch gar nix gelesen, ob das geht.) Oder hast für alle Systeme grundsätzlich immer Ersatzplatten auf Lager? Oder Du führst immer eine Datenmigration durch (Platte entfernen + rebalance)?

[schorsch_76]

Ich kann dir soviel sagen: Ich nutze im NAS Debian mit 3x 4 TB WD Red im btrfs RAID1C3 Verbund. Bisher ist alles super.Auf allen anderen Rechnern nutze ich auch btrfs schon seit vielen Jahren. Auch am Raspi hab ich btrfs genutzt. War Problemlos.

Bsp. Hier

Code: Alles auswählen

RAID1C3	OK	mostly OK		reading from mirrors in parallel can be optimized further (see below[/quote]

Damit hab ich keinerlei Probleme.

Oder das hier

Out-of-band dedupe OK mostly OK (reflink), heavily referenced extents have a noticeable performance hit (see below)
File range cloning OK mostly OK (reflink), heavily referenced extents have a noticeable performance hit (see below)

Device Replace, ja bei jedem Raid kann hier was schief gehen....

Wenn du mal in den ext4 Changelog des Kernels rein schaust, machst du auch schnell die Augen wieder zu ...

Code: Alles auswählen

git log --pretty=format:"%h %s" --graph fs/ext4
* 70e42feab2e20 ext4: fix possible double unlock when moving a directory
*   40d0c0901e6c1 Merge tag 'ext4_for_linus_stable' of git://git.kernel.org/pub/scm/linux/kernel/git/tytso/ext4
|\  
| * f5361da1e60d5 ext4: zero i_disksize when initializing the bootloader inode
| * f57886ca1606b ext4: make sure fs error flag setted before clear journal error
| * eee00237fa5ec ext4: commit super block if fs record error when journal record without error
| * 62913ae96de74 ext4, jbd2: add an optimized bmap for the journal inode
| * 2b96b4a5d9443 ext4: fix WARNING in ext4_update_inline_data
| * 1dcdce5919115 ext4: move where set the MAY_INLINE_DATA flag is set
| * 3c92792da8506 ext4: Fix deadlock during directory rename
| * 7fc1f5c28ae4c ext4: Fix comment about the 64BIT feature
| * c993799baf9c5 ext4: fix another off-by-one fsmap error on 1k block filesystems
| * c9f62c8b2dbf7 ext4: fix RENAME_WHITEOUT handling for inline directories
| * 60db00e0a1490 ext4: make kobj_type structures constant
| * ffec85d53d0f3 ext4: fix cgroup writeback accounting with fs-layer encryption
* | b07ce43db665a Merge tag 'ext4_for_linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tytso/ext4
|\| 
| * e3645d72f8865 ext4: fix incorrect options show of original mount_opt and extend mount_opt2
| * 0813299c586b1 ext4: Fix possible corruption when moving a directory
| * 172e344e6f82d ext4: init error handle resource before init group descriptors
| * 0f7bfd6f8164b ext4: fix task hung in ext4_xattr_delete_inode
| * 3039d8b869240 ext4: update s_journal_inum if it changes after journal replay
| * 5cd740287ae5e ext4: fail ext4_iget if special inode unallocated
| * d99a55a94a0db ext4: fix function prototype mismatch for ext4_feat_ktype
| * 7fc51f923ea6b ext4: remove unnecessary variable initialization
| * 3f5424790d437 ext4: fix inode tree inconsistency caused by ENOMEM
| * f31173c19901a ext4: refuse to create ea block when umounted
| * 1e9d62d252812 ext4: optimize ea_inode block expansion
| * 08abd0466ec91 ext4: remove dead code in updating backup sb
| * 240930fb7e6b5 ext4: dio take shared inode lock when overwriting preallocated blocks
| * 934b0de1e9fde ext4: don't show commit interval if it is zero
| * 11768cfd98136 ext4: use ext4_fc_tl_mem in fast-commit replay path
| * 3478c83cf26bb ext4: improve xattr consistency checking and error reporting
* |   d2980d8d82655 Merge tag 'mm-nonmm-stable-2023-02-20-15-29' of git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm
|\ \  
| * | 3ee2a3e7c1ca3 fs/ext4: use try_cmpxchg in ext4_update_bh_state
* | |   3822a7c40997d Merge tag 'mm-stable-2023-02-20-13-37' of git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm
|\ \ \  
| * | | 1c71222e5f239 mm: replace vma->vm_flags direct modifications with modifier calls
| * | | d585bdbeb79aa fs: convert writepage_t callback to pass a folio
| * | | 50ead2537441f ext4: convert mpage_prepare_extent_to_map() to use filemap_get_folios_tag()
| * | | e8dfc854eef20 ext4: convert mext_page_double_lock() to mext_folio_double_lock()
| |/ /  
* | |   4a7d37e824f57 Merge tag 'hardening-v6.3-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/kees/linux
|\ \ \  
| * | | 118901ad1f25d ext4: Fix function prototype mismatch for ext4_feat_ktype
| |/ /  
* | |   6639c3ce7fd21 Merge tag 'fsverity-for-linus' of git://git.kernel.org/pub/scm/fs/fsverity/linux
|\ \ \  
| * | | 51e4e3153ebc3 fscrypt: support decrypting data from large folios
| * | | db85d14dc5c56 ext4: allow verity with fs block size < PAGE_SIZE
| * | | 5e122148a3d57 ext4: simplify ext4_readpage_limit()

Facebook aka. Meta nutzt es auch auf allen ihren Servern [1] .... Was will ich dann viel sagen .... Weis ich mehr als die Kernel Programmierer die Meta hier beschäftigt? Ich glaube nicht. Es ist am Ende immer eine Abwägung.

[1] https://facebookmicrosites.github.io/bt ... ebook.html

Hier meine Info zu meinem "großen" Raid1C3

Code: Alles auswählen

root@nas-dsm:/mnt/data-btrfs# btrfs fi usage .
Overall:
    Device size:                  10.92TiB
    Device allocated:              4.78TiB
    Device unallocated:            6.14TiB
    Device missing:                  0.00B
    Device slack:                    0.00B
    Used:                          4.60TiB
    Free (estimated):              2.08TiB      (min: 2.08TiB)
    Free (statfs, df):             2.08TiB
    Data ratio:                       3.00
    Metadata ratio:                   3.00
    Global reserve:              512.00MiB      (used: 0.00B)
    Multiple profiles:                  no

Data,RAID1C3: Size:1.57TiB, Used:1.53TiB (97.57%)
   /dev/disk/by-partlabel/data1    1.57TiB
   /dev/sdc1       1.57TiB
   /dev/disk/by-partlabel/data3    1.57TiB

Metadata,RAID1C3: Size:24.00GiB, Used:2.35GiB (9.81%)
   /dev/disk/by-partlabel/data1   24.00GiB
   /dev/sdc1      24.00GiB
   /dev/disk/by-partlabel/data3   24.00GiB

System,RAID1C3: Size:32.00MiB, Used:304.00KiB (0.93%)
   /dev/disk/by-partlabel/data1   32.00MiB
   /dev/sdc1      32.00MiB
   /dev/disk/by-partlabel/data3   32.00MiB

Unallocated:
   /dev/disk/by-partlabel/data1    2.04TiB
   /dev/sdc1       2.04TiB
   /dev/disk/by-partlabel/data3    2.04TiB
root@nas-dsm:/mnt/data-btrfs# btrfs device stats .
[/dev/sdb1].write_io_errs    0
[/dev/sdb1].read_io_errs     0
[/dev/sdb1].flush_io_errs    0
[/dev/sdb1].corruption_errs  0
[/dev/sdb1].generation_errs  0
[/dev/sdc1].write_io_errs    0
[/dev/sdc1].read_io_errs     0
[/dev/sdc1].flush_io_errs    0
[/dev/sdc1].corruption_errs  0
[/dev/sdc1].generation_errs  0
[/dev/sdd1].write_io_errs    0
[/dev/sdd1].read_io_errs     0
[/dev/sdd1].flush_io_errs    0
[/dev/sdd1].corruption_errs  0
[/dev/sdd1].generation_errs  0
root@nas-dsm:/mnt/data-btrfs# btrfs device usage .
/dev/disk/by-partlabel/data1, ID: 1
   Device size:             3.64TiB
   Device slack:              0.00B
   Data,RAID1C3:            1.57TiB
   Metadata,RAID1C3:       24.00GiB
   System,RAID1C3:         32.00MiB
   Unallocated:             2.04TiB

/dev/sdc1, ID: 2
   Device size:             3.64TiB
   Device slack:              0.00B
   Data,RAID1C3:            1.57TiB
   Metadata,RAID1C3:       24.00GiB
   System,RAID1C3:         32.00MiB
   Unallocated:             2.04TiB

/dev/disk/by-partlabel/data3, ID: 3
   Device size:             3.64TiB
   Device slack:              0.00B
   Data,RAID1C3:            1.57TiB
   Metadata,RAID1C3:       24.00GiB
   System,RAID1C3:         32.00MiB
   Unallocated:             2.04TiB

[wanne]

Ich finde es für mich in meiner Umgebung - wie bereits geschrieben - grundsätzlich absolut akzeptabel für ein paar Tage ein Array degraded laufen zu lassen.

Akzeptabel. Aber warum, wenn man es bei btrfs nicht muss? Du beschwerst dich doch auch nicht, dass man keinen Haflinger vor deinen Ferrari spannen kann. Auch wenn der für die Fahrt zum Nachbarn ausreichend wäre.

Ist das grundsätzlich so, dass man danach das Btrfs kaputt gemacht hat, wenn man das tut?

degraded ist per default read only. – Also nein. Du kannst es auch einmalig rw machen, wenn du dann remove missing aufrufst. Nur wenn dir in der kurzen Zeitspanne der Strom ausfällt hast du eventuell ein Problem.

Das heisst, wenn eine Platte bei Dir ausfällt und Du hast gerade keine Ersatzplatte auf Lager, dann schaltest Du den Server ab, bis eine Ersatzplatte da ist, fährst den Server dann wieder hoch und ersetzt dann die Platte?

Nein. Einfach btrfs remove missing. Damit gibt man btrfs zu erkennen, dass die Platte kaputt ist und nicht mehr zurück kommt. Dann läuft es auch nicht mehr degraded. – Wie gesagt: Ausnahme ist, wenn du nur 2 platten hast.

Oder Du führst immer eine Datenmigration durch (Platte entfernen + rebalance)?

Hast du halt 2 rebuilds statt einem. IMHO tut das nicht weh. Aber im allgemeinen ist Festplattenplatz so billig, dass man einfach RAID1C2 machen kann und sich so den ganzen Ärger sparen.

[jph]

Ich bin nur Privatanwender/Hobbyist, daher sind meine Erfahrungen nur eingeschränkt auf ein professionelles Umfeld übertragbar.

btrfs nutze ich seit Jessie, damals noch mit Backports-Kernel. Zunächst auf meinem selbstgebauten Fileserver, mittlerweile auch auf dem Laptop, auf dem ich tippe. In der Zeit habe ich btrfs nur einmal geschrottet, indem ich im laufenden Betrieb eine Platte herausgezogen hatte. Eigentlich wollte ich einen leeren Slot öffnen. Der SATA-Controller des Servers ist nicht hotplug-fähig.

Weshalb habe ich mich seinerzeit für btrfs entschieden?

• Integriertes RAID1
• Snapshots. Diverser Krempel läuft in LXC-Containern, die lassen sich mit btrfs ziemlich einfach snapshotten. Das zunächst lokal und schnell mit borgmatic erzeugte Backup wird mit btrbk via SSH auf einen entfernten Server kopiert, was dann wieder länger dauert.
• Im Kernel-Tree, kein externes Modul
• Neugierde

Das Ziel des oben genannten Remote-Backups mit btrbk ist ein Raspberry Pi 4, an den eine USB-Platte mit btrfs angeschlossen ist. Auch diese Kombination funktioniert bislang tadellos.

Edit: Wöchentlich läuft ein Balance und monatlich ein Scrub, automatisiert über btrfsmaintenance.

Edit: In der öffentlichen Darstellung/den meisten Diskussionen kann ZFS übers Wasser gehen, während btrfs im Waschbecken ertrinkt. Dass dieses arg einseitige Bild nicht der Realität entspricht, verkennen nur Narren. (Das ist ein bisschen wie eine Unterhaltung mit Tesla-Fanboys, für die sind alle anderen Hersteller ja auch nur Stümper.)

Full Disclosure: Ich bin der Autor von btrfs.

[KP97]

@jph
Das ist ein ausgezeichneter Wiki-Artikel.
Ich wollte mich immer schon mal mit btrfs bschäftigen, jetzt hab ich was zu lesen, danke dafür.

[chrbr]

Edit: In der öffentlichen Darstellung/den meisten Diskussionen kann ZFS übers Wasser gehen, während btrfs im Waschbecken ertrinkt.

So etwas habe ich noch nie gelesen. Dein WIKI ist wirklich lesenswert. Das ist eine sehr gute und scheinbar auch aktuelle Einführung für Leute wie mich, die sich mit BTRFS nicht auskennnen.

[heisenberg]

Ich spiele gerade mal wieder kurz damit rum und verstehe es jetzt mehr davon.

Mir war nicht klar, dass der btrfs device remove missing einfach die Daten auf die anderen verfügbaren Geräte repliziert und so den Normalzustand wieder herstellt. Im Endeffekt funktioniert btrfs-multidevice mit der jeweils notwendigen Mindestanzahl von Platten erst grundsätzlich benutzbar (raid1 => 3 Platten. raid1c3 => 4 Platten, raid1c4 => 5 Platten). Dann kann eine ausfallen und die übrigen können das aufnehmen. Wenn das FS zu voll ist, dann knallt's aber hier schon. Besser wird es dann, wenn noch 1-3 mehr Platten da sind, da sich die Daten dann besser verteilen können. Also die entsprechende passende Anzahl von Platten vorausgesetzt ist das schon sehr nett.

Wenn man halt grundsätzlich diverse RAIDs mit nur 2 Platten hat, dann ist btrfs-multidevice da eher ungünstig, weil man dann zwingend umkonvertieren muss. Aber gerade dann, wenn eine Platte wegfliegt, die andere noch zu belasten ist ja der typische Use-Case um sich die zweite alte Platte auch noch wegzuschießen.

Die Art und Weise, das btrfs bei diversen Situationen einfach auf read-only geht, finde ich seltsam und unpraktisch. Da würde ich mir wünschen, dass btrfs da eher prüft, ob das, was es vorhat nicht vielleicht zu Fehlern führt, es dann halt sein lässt, den Prozess mit einem Fehler abbricht und dann normal weiter macht. Beispielsweise habe ich einen btrfs balance bei einem vollen btrfs ausgeführt. => read-only. Das könnte man doch sicher vermeiden.

Und wie oben schon geschrieben: Mir ist das lieber, dass wenn eine Platte komplett wegfliegt, alles normal weiter läuft, besonders wenn noch Redundanz da ist (ab raid1c3). Ich vermute, dass das da automatisch in den Read-Only-Modus geht. Das kann ich jetzt mit loop-devices nicht darstellen, weil ich die nicht erzwungen entfernen kann.

Nachtrag zu: Wenn das FS zu voll ist, dann knallt's aber hier schon.

Das trifft wohl besonders dann zu, wenn man stark unterschiedliche Plattengrößen verwendet.

Beispiel 1

5 Platten. Davon 4 x 4 TB und 1 x 10 TB mit einem RAID1C4. (Geschätzte Maximalbelegung wenn alle Platten funktionsfähig: 5 TB)

Plattenbelegung 5 TB (Rohdatenplattenbelegung 20 TB). Eine 4 TB Platte fällt aus -> alle übrigen müssten jetzt jeweils 5 TB Daten aufnehmen. Geht natürlich nicht. Hoffentlich geht dann noch die Datenkonvertierung.

Beispiel 2

6 Platten. Davon 4 x 4 TB und 2 x 10 TB mit einem RAID1C4. (Geschätzte Maximalbelegung wenn alle Platten funktionsfähig: 8 TB).

Plattenbelegung 6 TB (Rohdatenplattenbelegung 24 TB) Eine 4 TB Platte fällt aus -> alle übrigen müssen 4 TB aufnehmen. Geht gerade noch so (?).

Beispiel 3

3 Platten. Davon 2 x 4 TB und 1 x 10 TB mit einem RAID1. (Geschätzte Maximalbelegung wenn alle Platten funktionsfähig sind: 8 TB)

Maximale Plattenbelegung des Dateisystems, die einen Ausfall einer (egal welcher Platte) ausgleichen kann: 4 TB.

Beispiel 4

4 Platten. Davon 3 x 4 TB und 1 x 10 TB mit einem RAID1. (Geschätzte Maximalbelegung, wenn alle Platten funktionsfähig sind: 11 TB)

Maximale Plattenbelegung des Dateisystems bei Ausfall einer 4 TB Platte, bei der RAID1 beibehalten werden kann: 8 TB.

Maximale Plattenbelegung des Dateisystems bei Ausfall der 10 TB Platte, bei der RAID1 beibehalten werden kann: 6 TB.

Hier mal die Visualisierung - hier mit 1 TB Datenblöcken - die ich mir da gemacht habe. (Das kann man bestimmt auch super mit Formeln ausdrücken). Hier für das Beispiel 4:

Code: Alles auswählen

Beispiel 4 - RAID1 - Normalzustand
                
4 4 4 10

a      a
  b    b
    c  c
d      d
  e    e
    f  f
g      g
  h    h
    i  i
j      j
  k k
  
4 4 4 10        22 / 2 => 11 TB

---
1 x 4 TB Platte fällt aus:

4 4 10

a    a
  b  b
c    c
  d  d
e    e
  f  f
g    g
  h  h

4 4  8        16 / 2 => 8 TB

---
1 x 10 TB Platte fällt aus:

4 4 4

a a
  b b
c   c
d d 
  e e
f   f

4 4 4      12 / 2 => 6 TB

Fazit

Da muss man aber schon sehr genau aufpassen, wie voll man die Dateisysteme macht. Das ist der große Unterschied zum traditionellen RAID: Der verfügbare Kapazität verändert sich beim Ausfall einer Platte. Bei einem traditionellen RAID war sie immer gleich. Bei Ausfall dann halt degraded. Das ist dann ein Zusatzpunkt, den man beachten muss.

Intuitiv denke ich: Umkonvertieren (RAID1c3 -> RAID1) bei einem Plattenausfall will ich eher nicht haben. Da würde ich eher zusätzliche Probleme erwarten.

[heisenberg]

Nachtrag 2:

Man kann ja btrfs in bestimmten Konstellationen degraded laufen lassen. Im Fall von einem RAID1 mit 2 Platten mit Sicherheit nicht, weil dann Single-Blöcke entstehen und das FS beim nächsten Reboot kaputt ist. Aber bei einem RAID1 mit z. B. 4 Platten? So what? Dann hat man halt für einen Teil der Daten gerade mal keine Redundanz. Wenn das FS gerade zu voll ist und alles andere wäre nur noch schwieriger? Und das Ganze nur, bis die Ersatzplatte ersetzt ist? Finde ich eine gute Option.

Ansonsten denke ich mir gerade, dass man das bei einem raid1c3 auch riskieren kann. Dann sind halt da nur 2 Kopien da, wenn eine Platte abraucht. Natürlich kann's auch andere Fehler geben und wenn man da den Schutzmechanismus (degraded) außer Kraft setzt, könnte es blöd werden (Datenverlust).

Verstehe ich irgend etwas falsch?

[wanne]

Man kann ja btrfs in bestimmten Konstellationen degraded laufen lassen. Im Fall von einem RAID1 mit 2 Platten mit Sicherheit nicht, weil dann Single-Blöcke entstehen und das FS beim nächsten Reboot kaputt ist. Aber bei einem RAID1 mit z. B. 4 Platten? So what? Dann hat man halt für einen Teil der Daten gerade mal keine Redundanz. Wenn das FS gerade zu voll ist und alles andere wäre nur noch schwieriger? Und das Ganze nur, bis die Ersatzplatte ersetzt ist? Finde ich eine gute Option.

Oops: Gerade noch mal nachgelesen. Ich dachte, dass btrfs das dann nicht mehr degraded nennt, da ja keine Probleme beim schreiben entstehen. Ist aber nicht der Fall. Sorry für die Verwirrung, die ich gestiftet habe.

Ansonsten denke ich mir gerade, dass man das bei einem raid1c3 auch riskieren kann. Dann sind halt da nur 2 Kopien da, wenn eine Platte abraucht. Natürlich kann's auch andere Fehler geben und wenn man da den Schutzmechanismus (degraded) außer Kraft setzt, könnte es blöd werden (Datenverlust).

Im allgemeinen weißt btrfs (im dmsg) schon auf Probleme hin. Wenn es rw mounted, dann kannst du das auch.

[heisenberg]

Also wenn ich jetzt gerade mal ein bisschen mit btrfs und RAID1 und Betrieb im degraded Mode rumspiele (Bookworm, Kernel 6.1.0-18-amd64), dann scheine ich das nicht kaputt zu bekommen.

Hinweis: Die Ausgaben sind nicht ganz korrekt, weil ich hier noch ein bisschen mehr rumgespielt habe, als ich das hier schrieb. Z. B. war das FS zu klein und der balance hat dann nicht funktioniert. Deswegen habe ich es zwischendurch nochmal vergrößert.

Erst mal ein Setup:

Code: Alles auswählen

for i in 1 2; do 
    dd if=/dev/zero bs=10G count=1 of=file$i
    losetup -f /dev/loop$i disk$i
    wipefs -f --all /dev/loop$i
done
mkfs.btrfs -mraid1 -draid1 /dev/loop0 /dev/loop1
mount /dev/loop0 /testbtrfs
cp -ax /bin/* /sbin/* /testbtrfs
umount /testbtrfs

Dann löse ich das eine Device mal auf und mounte degraded neu und kopiere mal ein paar Daten drauf und unmounte dann wieder:

Code: Alles auswählen

losetup -d /dev/loop1
mount -o degraded,rw /dev/loop0 /testbtrfs
cp -ax /usr/share/{locale,fonts} /testbtrfs
umount

Dann sieht der btrfs filesystem df /testbtrfs ungefähr so aus:

Code: Alles auswählen

# btrfs filesystem df /testbtrfs
Data, single: total=1.40GiB, used=1.38GiB
Data, RAID1: total=2.63GiB, used=2.62GiB
System, RAID1: total=32.00MiB, used=16.00KiB
Metadata, RAID1: total=256.00MiB, used=68.31MiB
GlobalReserve, single: total=9.06MiB, used=0.00B
WARNING: Multiple block group profiles detected, see 'man btrfs(5)'
WARNING:    Data: single, raid1

Also nachdem, was ich bisher weiss, ist das jetzt der worst case. Wenn ich das (unmount, degraded remount, wieder Daten draufkopieren) ein paar mal wiederhole, dann sieht es noch genauso aus. Meine Erwartung wäre jetzt, dass das FS mal kaputt geht: Final Read-only. Aber nix da: Das funktioniert, wie es soll.

Dann simuliere ich mal den device replace mit ...

Code: Alles auswählen

losetup /dev/loop1 file1
wipefs -f --all /dev/loop1 (einfach mal das fs auf dem bisherigen device löschen)
umount /testbtrfs
mount /dev/loop0 /testbtrfs
btrfs scrub start /testbtrfs

Anmerkung: Dafür gibt's ja eigentlich btrfs replace - ich weiss. Jedenfalls: Beide Devices sind wieder da.

Gibt es noch das Problem ...

Code: Alles auswählen

# btrfs filesystem df /testbtrfs
...
WARNING: Multiple block group profiles detected, see 'man btrfs(5)'
WARNING:    Data: single, raid1

Dann noch einen balance hinterher ...

Code: Alles auswählen

btrfs balance start -mconvert=raid1 -dconvert=raid1

... und alles ist wieder knorke:

Code: Alles auswählen

# btrfs filesystem df /testbtrfs

Data, RAID1: total=4.00GiB, used=4.00GiB
System, RAID1: total=32.00MiB, used=16.00KiB
Metadata, RAID1: total=256.00MiB, used=69.45MiB
GlobalReserve, single: total=10.30MiB, used=0.00B

Habe ich das jetzt so richtig verstanden, dass der Fehler, der dabei üblicherweise passiert, der ist, dass die Benutzer nicht verstanden haben, dass da jetzt single Blöcke drin sind, d. h. fehlende Redundanz und wenn man dann halt erneut die Platte tauscht und diesmal halt die andere, auf der dann die einzigen Exemplare der Single-Blöcke waren, dann war's das, weil die entsprechenden Daten halt weg sind? (Ah. Nee. Das war nur der Bug das Verhalten, der dass seit 4.14 gefixt verändert wurde.)

----

Wenn das so ist, wie das für mich jetzt aussieht, dann würde ich die Mount-Option "degraded" in die fstab reinhauen. Mein Monitoring sagt mir dann schon (nachdem ich es dem eingebaut habe), dass "btrfs filesystem df" eine Warnung ausgibt, welche dann auch dringend gefixt werden sollte - zumindest auf jeden Fall vor einem neuen Plattentausch. ... und Bezug nehmend zu meinem Ursprungsbeitrag ... sehe ich das so nicht mehr als NoGo an. Ok. Das ist dann halt ein Schritt mehr. Aber wenn man die Platte tauscht und weiss, was zu tun ist, dann ist das ja ok.

[wanne]

Ja. Früher war das ganze Dateisystem RO, wenn passende Redundanz fehlt. Jetzt passiert das nur noch mit einzelnen Fällen bei Dateien, die nicht schreibbar sind. (Kannst sie dann aber weg kopieren.) Rein theoretisch sollte das passieren, wenn du in nem RAID1 mit 2 Platten einen Ordner anlegst dann im degraded mode eine Datei rein schreibst und dann wenn das device wieder da ist, ohne balance die Datei änderst. Reproduzieren kann ich das jetzt aber auch nicht.

dann würde ich die Mount-Option "degraded" in die fstab reinhauen

während degraded alleine dir erstmal die Daten erst mal nicht schrottet kann das halt zu ro für einzelne Dateien führen. Sprich: Du solltest das degraded eigentlich nur machen, wenn du weißt, dass die passende Platte nicht zurück kommt und du vorhast ein remove zu machen. Sobald du 3 Platten in deinem RAID1 hast, ist anyway wurst.

[heisenberg]

Also wenn ich das Script hier starte ...

Code: Alles auswählen

#!/bin/bash

#
# btrfs raid1 test
#
#    - have 2 disks
#    - repeatedly mount degraded with alternating disk offline
#    - append data to same file
#    - umount and start over
#

mylog() {
        echo "$(date) : $*"
}

btrfs_change() {

        umount /testbtrfs
        add_nr=$1
        del_nr=$2
        mylog "changing btrfs to enabled: $add_nr disabled: $del_nr"
        losetup | grep -q /dev/loop$add_nr || losetup /dev/loop$add_nr /backup/testing/disk$add_nr
        losetup -d /dev/loop$del_nr
        mount -o rw,degraded /dev/loop$add_nr /testbtrfs

}

do_write() {
        echo "$(date) : v$1" >>/testbtrfs/testdir1/testfile
}

i=1
while :;do 
        btrfs_change 1 0
        do_write "$i"
        btrfs_change 0 1
        do_write "$((i+1))"
        ((i=i+2))
done

... dann bricht mir der Scrub ab:

Code: Alles auswählen

# btrfs scrub start /testbtrfs
....
# btrfs scrub status /testbtrfs

UUID:             dae8405b-26f3-48b1-8340-bb4b30913367
Scrub started:    Fri Feb 23 18:48:09 2024
Status:           aborted
Duration:         0:00:02
Total to scrub:   13.35GiB
Rate:             2.39GiB/s
Error summary:    no errors found

Code: Alles auswählen

# dmesg

[18772.285963] BTRFS info (device loop1): scrub: started on devid 1
[18772.285973] BTRFS info (device loop1): scrub: started on devid 2
[18773.680211] BTRFS error (device loop1): tree first key mismatch detected, bytenr=44133711872 parent_transid=724 key expected=(18446744073709551606,128,49086353408) has=(18446744073709551606,128,49107329024)
[18773.683933] BTRFS info (device loop1): scrub: not finished on devid 1 with status: -117
[18773.700993] BTRFS error (device loop1): tree first key mismatch detected, bytenr=44133711872 parent_transid=724 key expected=(18446744073709551606,128,49086353408) has=(18446744073709551606,128,49107329024)
[18773.703256] BTRFS info (device loop1): scrub: not finished on devid 2 with status: -117

Ausgabe der Testdatei:

Code: Alles auswählen

# cat /testbtrfs/testdir1/testfile
...
Fr 23. Feb 18:37:47 CET 2024: v351
Fr 23. Feb 18:37:47 CET 2024: v352
Fr 23. Feb 18:37:47 CET 2024: v353
Fr 23. Fecat: testfile: Eingabe-/Ausgabefehler

# dmesg 
...
[18872.035969] BTRFS error (device loop1): tree first key mismatch detected, bytenr=44133711872 parent_transid=724 key expected=(18446744073709551606,128,49086353408) has=(18446744073709551606,128,49107329024)
[18872.036015] BTRFS error (device loop1): tree first key mismatch detected, bytenr=44133711872 parent_transid=724 key expected=(18446744073709551606,128,49086353408) has=(18446744073709551606,128,49107329024)
[18872.036325] BTRFS error (device loop1): tree first key mismatch detected, bytenr=44133711872 parent_transid=724 key expected=(18446744073709551606,128,49086353408) has=(18446744073709551606,128,49107329024)

Datei kopieren und löschen geht. (Kopie erzeugt auch einen E/A-Fehler.)

Dann nochmal btrfs scrub start (aborted) und dann das hier:

Code: Alles auswählen

[19047.621831] BTRFS error (device loop1): tree first key mismatch detected, bytenr=44133711872 parent_transid=724 key expected=(18446744073709551606,128,49086353408) has=(18446744073709551606,128,49107329024)
[19047.623042] BTRFS: error (device loop1: state A) in do_free_extent_accounting:2846: errno=-117 Filesystem corrupted
[19047.623050] BTRFS info (device loop1: state EA): forced readonly
[19047.623055] BTRFS error (device loop1: state EA): failed to run delayed ref for logical 49086353408 num_bytes 10489856 type 178 action 2 ref_mod 1: -117
[19047.623065] BTRFS: error (device loop1: state EA) in btrfs_run_delayed_refs:2150: errno=-117 Filesystem corrupted

[heisenberg]

Das FS nochmal neu eingehangen und einen Scrub gemacht. Der geht durch. (Die problematische Datei habe ich vorher gelöscht.). Es traten dann aber später andere Probleme auf und das FS ist wieder read-only gegangen.

Ich habe das gleiche nochmal wie oben gemacht. Nur mit einem ordentlichen mount vor jedem degraded mount. Die Daten waren auch da nicht mehr konsistent.

Also wenn man will, kriegt man das schon kaputt.

Also dann doch mal lieber degraded in fstab sein lassen...

[heisenberg]

Ich bin jetzt auch nochmal zu btrfsck gekommen und sehe, dass es da wohl sehr übel aussieht, wenn man mal da ankommt, dass das FS tatsächlich Fehler aufweisen sollte.

Es gibt da zwar so ein paar Empfehlungen, was man tun sollte ...

https://en.opensuse.org/SDB:BTRFS#How_t ... filesystem

... aber der Kern hinter allem ist: "Sorry. Unser Dateisystemcheck kann nix reparieren". Das stimmt mich dann doch mal sehr nachdenklich. (-> Not for heavy production use).

[wanne]

... aber der Kern hinter allem ist: "Sorry. Unser Dateisystemcheck kann nix reparieren". Das stimmt mich dann doch mal sehr nachdenklich. (-> Not for heavy production use).

Es gibt es scrub. btrfsck wurde defakto nur nachgeliefert um das Verlangen der Distros nachzufolgen, die einen einheitlichen Ablauf für alle Dateisysteme haben wollten. Hast du mal deinen obigen versuch mit nem normalen RAID1 und sagen wir einem XFS gemacht? 100% dass da keine Datei mehr den Inhalt hat, den sie haben sollte.
Ja. Ein fsck.ext4 macht dir mit den richtigen Optionen sogar aus nem üblichen XFS ein valides ext4. Aber keine Datei und kein Dateiname wird der gleiche bleiben. Das gleiche kannst du auch mit mkfs.btrfs erreichen.
In absolut jedem Fall stehst du mit einem btrfs besser da als mit einem RAID. Bei verfälschten Daten korrigiert es. Bei fehlenden kann es halt auch nichts machen. Wenn du btrfs als nicht produktiv betrachtest, dann eben auch kein RAID1!

Der große Unterschied zwischen btrfs und nem RAID ist, dass btrfs dank Checksummen im Zweifelsfall Fehlermeldungen statt Datenmüll liefert und so die Fehler mehr auffallen. Und zwar mittlerweile pro Block. Da sind also keine noch nutzbaren Daten. Nur Müll. Das gleiche RAID verhalten kannst du billiger erreichen, in dem du einfach jedes mal von /dev/urandom ließt und nach /dev/null schreibst wenn btrfs einen Fehler liefert.

[heisenberg]

... aber der Kern hinter allem ist: "Sorry. Unser Dateisystemcheck kann nix reparieren". Das stimmt mich dann doch mal sehr nachdenklich. (-> Not for heavy production use).

Es gibt es scrub.

Scrub und Dateisystemcheck sind zwei ganz verschiedene Paar Schuhe. Ein Scrub behebt Datenfehler, die aufgrund der Checksumme erkannt und bei Redundanz repariert werden können. Ein Dateisystemcheck ist eine strukturelle Validierung eines Dateisystems. Wenn Du jetzt schreibst, dass eine Validierung unnötig ist, dann bist Du also der Meinung, dass btrfs nahezu fehlerfrei ist und jegliche Fehler in der Struktur des FS nicht vorkommen können? Bist Du weiterhin der Meinung, dass auch alle Dateisystemfehler aufgrund von unsachgemäßer Bedienung nicht reparabel sein sollen? Damit meine ich jetzt nicht meine mutwillige Zerstörung von oben sondern vielmehr Situationen, die aufgrund von einzelnen falschen Befehlen entstehen können.

Ich sehe einen fsck mit einer Fähigkeit zur Dateisystemreparatur als essentiell an. Bis dahin bleibt es für mich ein Dateisystem, dass ich nur begrenzt und in unkritischen Anwendungsfällen einsetzen möchte.

Für mich wäre so eine Haltung eines Projektes (=Unwillen zu FS-Check mit Reparaturfähigkeit) mit dieser zentralen Bedeutung nicht akzeptabel. Meine bisherige Beobachtung bzgl. btrfs lässt mich da aber insgesamt hoffen, dass es in 5-10 Jahren den entsprechenden fsck geben wird, weil man da wahrscheinlich ein Einsehen haben wird.

In absolut jedem Fall stehst du mit einem btrfs besser da als mit einem RAID. Bei verfälschten Daten korrigiert es. Bei fehlenden kann es halt auch nichts machen. Wenn du btrfs als nicht produktiv betrachtest, dann eben auch kein RAID1!

Ja. Bei RAID1 können Datenfehler im laufenden Betrieb vorkommen. Aber dies betrifft üblicherweise nicht das komplette Dateisystem. Wenn ein unbehebbarer Fehler im Btrfs ist, dann ist das aber sehr wahrscheinlich schon der Fall. D. h. entweder readonly oder kaputt.

Ja. Ein fsck.ext4 macht dir mit den richtigen Optionen sogar aus nem üblichen XFS ein valides ext4. Aber keine Datei und kein Dateiname wird der gleiche bleiben. Das gleiche kannst du auch mit mkfs.btrfs erreichen.

Nur weil es extreme Möglichkeiten gibt, den fsck(.ext4) anzuwenden heisst das IMO nicht, dass der grundlegende Einsatzzweck nicht nützlich und hilfreich ist.

Unterschied zwischen ZFS und btrfs hinsichtlich wiederherstellung nach degraded operation

Der Unterschied scheint hier zu sein, dass ZFS die Neusynchronisation nach dem degraded automatisch macht, wenn es die braucht (resilvering) und bei btrfs muss wohl zwingend manuell ein btrfs balance start bzw. btrfs scrub start angestossen werden. Mir ist Ersteres deutlich sympatischer, v. a. deswegen, weil ich mir gerade unsicher bin, wann denn immer eine Neusynchronisation gebraucht wird - gerade in unklaren Zuständen - und eine fehlende Neusynchronisation bei btrfs möglicherweise die Katastrophe auslöst, v. a. wenn das häufiger geschieht.

[wanne]

und eine fehlende Neusynchronisation bei btrfs möglicherweise die Katastrophe auslöst, v. a. wenn das häufiger geschieht.

Nein. Umgekehrt. Klassisches RAID1 löst dir dann Katastrophen aus. Du merkst es nur später. Wenn du auf beiden Platten für die gleichen Ordnerstrukturen verweise an unterschiedliche Stellen mit unterschiedlichen Inhalten hast, schreibt dein ext4 munter abwechselnd auf die freien Blöcke der jeweiligen Platten. Und dein RAID synchronisiert das munter über die Daten der andern Platte. Wenn deine Platte relativ leer ist, mag dir das am Anfang nicht auffallen: Aber so bekommst du zwei unterschiedliche Dateisystem die immer weiter auseinander driften und dabei Daten auf dem anderen vernichten. Ein fsck verschnellert den Vorgang nur. Der Schaden ist mit einem möglichst schnellen sync maximal einzugrenzen nicht zu beheben.

btrfs und zfs kennen das Problem und haben deswegen alles daran gesetzt dieses Problematik zu vermeiden: btrfs indem es ohne passende Redundanz nicht mounted ZFS indem es "alte" Platten nicht wieder aufnimmt.
Beiden kannst du dann manuell im Zweifelsfall sagen, wie sie sich anders verhalten sollen.

Der Unterschied scheint hier zu sein, dass ZFS die Neusynchronisation nach dem degraded automatisch macht, wenn es die braucht (resilvering) und bei btrfs muss wohl zwingend manuell ein btrfs balance start bzw. btrfs scrub start angestossen werden.

ZFS hat die gleiche replace/delete syntax um auf fehlende devices zu reagieren wie zfs. ZFS fügt vormals fehlende devices nicht erneut zum pool hinzu. Statt einem btrfs scrub musst du also ein online ausführen, dass dann seinerseits ein scrub anstößt. Du hast also genau gleich viele Befehle. Der einzige unterschied bleibt, dass ZFS automatisch in degraded wechselt.

Scrub und Dateisystemcheck sind zwei ganz verschiedene Paar Schuhe. Ein Scrub behebt Datenfehler, die aufgrund der Checksumme erkannt und bei Redundanz repariert werden können. Ein Dateisystemcheck ist eine strukturelle Validierung eines Dateisystems.

Wie du selbst schon gemerkt hast, überprüft scrub nicht nur Checksummen. Sondern checkt auch die Validität des Ordnerbaumes und konsistente Daten (Datum als Plural von Kalenderdatum nicht von Bit). Und gegen btrfs check (ohne --repair) ist nichts einzuwenden... Es gibt btrfs rescue um derartige Fehler zu beheben.

Ich sehe einen fsck mit einer Fähigkeit zur Dateisystemreparatur als essentiell an. Bis dahin bleibt es für mich ein Dateisystem, dass ich nur begrenzt und in unkritischen Anwendungsfällen einsetzen möchte.

Das ist dein gutres Recht. Bescheuert bleibt die Ansicht trotzdem. Lass mich ein anderes Beispiel nennen: Seit 1970 haben die USA einen umstrittenen Abschuss mit einer Bordkanone. Die Bordkanone und ihre Befestigung macht aber einen großen Teil der Nutzlast aus. Im F-35 wollten sie entsprechend Bordkanone zur Verbesserung der Flugeigenschaften beseitigen. Das Militär Allen voran die US-Navy protestierte. Was wenn die Raketen aus gehen?! Dann kann ich mich gar nicht mehr verteidigen! Ignorierend, dass es viel häufiger vorkommt, dass man wegen des schlechteres Flugzeugs viel häufiger zusätzlich in derartige Situationen kommt als einem eine Maschinenkanonen in solchen helfen kann. Heute fliegt der F-36 praktisch immer ohne Maschinenkanone und stattdessen mit zusätzlichen Waffen bestückt. Das schwerere Design, das eine Kanone unterstützen kann, erben sie aber alle von der A-Variante.
Das gleiche hier: Die btrfs Entwickler sind ja bereits eingeknickt und haben ein --repair nachgeliefert. Sinnvoll war es nicht. Und ich gehe jede Wette ein 90% der Leute, die Datenverlust haben haben den weil es die Option gibt und wären im Nachhinein froh gewesen, wenn das Dateisystem nein gesagt hätte und sie halt entweder über btrfs rescue gestolpert wären oder halt btrfs device delete oder btrfs restore hätten machen müssen.

Nur weil es extreme Möglichkeiten gibt, den fsck(.ext4) anzuwenden heisst das IMO nicht, dass der grundlegende Einsatzzweck nicht nützlich und hilfreich ist.

Ja. Aber in anderen Fällen braucht btrfs ja kein fsck. Relevant wird das erst wenn das Dateisystem so kaputt ist, dass es sich nicht mal mehr mounten lässt. Das dürfte seit Kernel 4.14 deutlich seltener der Fall sein, als das auch kein fsck.ext4 mehr sinnvoll hilft.

[heisenberg]

Für die Mitlesenden: Ich beziehe mich ab hier explizit nicht mehr auf Wannes Ausführungen und gehe aus persönlichen Gründen auch nicht mehr darauf ein.

Unterschied zwischen ZFS und btrfs hinsichtlich wiederherstellung nach degraded operation

Der Unterschied scheint hier zu sein, dass ZFS die Neusynchronisation nach dem degraded automatisch macht, wenn es die braucht (resilvering) und bei btrfs muss wohl zwingend manuell ein btrfs balance start bzw. btrfs scrub start angestossen werden. Mir ist Ersteres deutlich sympatischer, v. a. deswegen, weil ich mir gerade unsicher bin, wann denn immer eine Neusynchronisation gebraucht wird - gerade in unklaren Zuständen - und eine fehlende Neusynchronisation bei btrfs möglicherweise die Katastrophe auslöst, v. a. wenn das häufiger geschieht.

Das bezog sich auf dieses Script, mit dem ich da weiterhin noch getestet habe:

Code: Alles auswählen

# btrfs/zfs raid1 test
#
#    - have 2 disks
#    - repeatedly do
#       * mount/import degraded only with disk-1
#       * umount/export
#       * mount/import fully with disk-1 + disk-2
#       * umount/export
#       * mount/import degraded only with disk-2
#       * umount/export
#       * mount/import fully with disk-1 + disk-2
#       * umount/export
#    - append data to same file
#    - umount and start over
#

ZFS erkennt hier, dass eine Festplatte einen alten Stand hat und führt automatisch einen resilver aus. Bei btrfs muss ich da selbst dran denken, sonst wäre das fs jetzt oder später irgendwann mal kaputt. Insofern ist bei mir die Erkenntnis wie gehabt: ZFS führt einen resilver aus, wenn es notwendig ist. Bei btrfs führt man lieber selbst einen scrub zu viel aus als einen zu wenig, wenn man sich unsicher sein sollte.