btrfs Probleme

[mischi]

Ich betreibe einen Linux Server mit Debian Stretch und aktuellem (4.12.13-1-bpo9+1) backport kernel.
Mit backuppc sichere ich meine Systeme zu Hause auf diesen Servern auf eine lokal angeschlossene Festplatte mit btrfs filesystem. Diese Lösung läuft seit langem so und war bisher ohne Auffäligkeiten.
Vor einigen Wochen häuften sich allerdings Abstürze auf dem System. Mittels meminfo identifzierte ich ein Memory Modul als defekt. Nachdem ich andere Speichermodule in dem Server habe, sind leider die kernel oopse geblieben. Bei der weiteren Analyse stellte ich feste, das das erwähnte btrfs fs für die backuppc Sicherung ständig Kernelmeldungen bringt.

Code: Alles auswählen

BTRFS warning (device sdf1): csum failed root 4015 ino 542516 off 5148672 csum 0x95ed7b76 expected csum 0x0088db31 mirror1

Zunächst hatte ich die Festplatte im Verdacht, die smart Werte sind ok und ich konnte mehrfach ohne Fehler die komplette Medienoberfläche nach /dev/null kopieren.

Also habe ich die kompletten Daten mittels rsync auf ein anderes fs kopiert mit dem Ziel das btrfs auf der problematischen Festplatte anschließend neuanzulegen.
Der rsync brauchte etliche Anläufe weil das ganze System zwischendurch mit BUG: soft lockup CPU stuck for 23s hing.
Gestern abend war das endlich durch und ich habe das FS neuangelegt und angefangen, die Daten mit rsync wieder zurückzukopieren.

Code: Alles auswählen

sudo rsync -avcAHX /mnt/archive.backup /mnt/archive

Heute morgen dann wieder kernel Fehler auf dem frischen btrfs Dateisystem. Ich versteh es langsam nicht mehr.

Code: Alles auswählen

Oct 19 07:19:54 fatblock kernel: [210309.346913] kernel BUG at /build/linux-RdeW6Z/linux-4.12.13/fs/btrfs/extent-tree.c:1907!
Oct 19 07:19:54 fatblock kernel: [210309.347721] invalid opcode: 0000 [#1] SMP
Oct 19 07:19:54 fatblock kernel: [210309.348492] Modules linked in: nfnetlink_queue nfnetlink_log nfnetlink bluetooth ecdh_generic rfkill uas usb_storage pl2303 ebtable_filter ebtables ip6table_filter ip6_tables iptable_filter cpufreq_userspace cpufreq_powersave cpufreq_conservative binfmt_misc bridge 8021q garp mrp stp llc stv6110x lnbp21 stv090x nct6775 hwmon_vid ext4 crc16 jbd2 fscrypto ecb mbcache intel_rapl x86_pkg_temp_thermal intel_powerclamp kvm_intel kvm ppdev crct10dif_pclmul crc32_pclmul ghash_clmulni_intel intel_cstate snd_hda_codec_realtek iTCO_wdt iTCO_vendor_support snd_hda_codec_generic snd_hda_codec_hdmi intel_uncore pcspkr sg intel_rapl_perf cp210x usbserial cdc_acm ddbridge snd_hda_intel dvb_core snd_hda_codec snd_hda_core snd_hwdep snd_pcm parport_pc snd_timer battery parport snd tpm_infineon soundcore intel_smartconnect
Oct 19 07:19:54 fatblock kernel: [210309.353933]  evdev mei_me ie31200_edac shpchp lpc_ich mei mfd_core eeprom nfsd coretemp auth_rpcgss nfs_acl loop lockd grace sunrpc ip_tables x_tables autofs4 btrfs raid10 raid1 raid0 multipath linear vfio_pci irqbypass vfio_virqfd vfio_iommu_type1 vfio hid_generic usbhid hid dm_mod raid456 async_raid6_recov async_memcpy async_pq async_xor async_tx xor raid6_pq libcrc32c crc32c_generic md_mod sd_mod crc32c_intel mxm_wmi aesni_intel ahci libahci i915 aes_x86_64 crypto_simd cryptd glue_helper libata i2c_algo_bit xhci_pci ehci_pci drm_kms_helper ehci_hcd xhci_hcd scsi_mod i2c_i801 r8169 mii usbcore drm usb_common fan thermal wmi video button
Oct 19 07:19:54 fatblock kernel: [210309.358496] CPU: 4 PID: 17066 Comm: btrfs-transacti Not tainted 4.12.0-0.bpo.2-amd64 #1 Debian 4.12.13-1~bpo9+1
Oct 19 07:19:54 fatblock kernel: [210309.359263] Hardware name: MSI MS-7823/H87M-G43 (MS-7823), BIOS V1.9 05/30/2015
Oct 19 07:19:54 fatblock kernel: [210309.359999] task: ffff9aa7c128d000 task.stack: ffffbaa64a3b0000
Oct 19 07:19:54 fatblock kernel: [210309.360741] RIP: 0010:insert_inline_extent_backref+0xd9/0xe0 [btrfs]
Oct 19 07:19:54 fatblock kernel: [210309.361454] RSP: 0018:ffffbaa64a3b3bf0 EFLAGS: 00010293
Oct 19 07:19:54 fatblock kernel: [210309.362155] RAX: 0000000000000000 RBX: 0000000000000001 RCX: 0000000000000001
Oct 19 07:19:54 fatblock kernel: [210309.362853] RDX: 0000000000000001 RSI: 0000000000000000 RDI: 0000000000000000
Oct 19 07:19:54 fatblock kernel: [210309.363553] RBP: ffff9aa840ea2000 R08: 0000000000003ce8 R09: ffffbaa64a3b3ad0
Oct 19 07:19:54 fatblock kernel: [210309.364220] R10: 0000000000000000 R11: 0000000000000003 R12: 0000000000000000
Oct 19 07:19:54 fatblock kernel: [210309.364875] R13: 0000000000000000 R14: 0000000000000000 R15: ffff9aa7c110f0e0
Oct 19 07:19:54 fatblock kernel: [210309.365515] FS:  0000000000000000(0000) GS:ffff9aa8deb00000(0000) knlGS:0000000000000000
Oct 19 07:19:54 fatblock kernel: [210309.366144] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
Oct 19 07:19:54 fatblock kernel: [210309.366758] CR2: 00007f5abaa1a81b CR3: 000000008c409000 CR4: 00000000001406e0
Oct 19 07:19:54 fatblock kernel: [210309.367387] Call Trace:
Oct 19 07:19:54 fatblock kernel: [210309.367988]  ? __btrfs_inc_extent_ref.isra.52+0x8d/0x280 [btrfs]
Oct 19 07:19:54 fatblock kernel: [210309.368591]  ? btrfs_merge_delayed_refs+0x63/0x590 [btrfs]
Oct 19 07:19:54 fatblock kernel: [210309.369182]  ? __btrfs_run_delayed_refs+0xa33/0x1260 [btrfs]
Oct 19 07:19:54 fatblock kernel: [210309.369762]  ? __switch_to+0x234/0x430
Oct 19 07:19:54 fatblock kernel: [210309.370340]  ? btrfs_run_delayed_refs+0x7a/0x270 [btrfs]
Oct 19 07:19:54 fatblock kernel: [210309.370944]  ? kmem_cache_alloc+0xbb/0x5a0
Oct 19 07:19:54 fatblock kernel: [210309.371528]  ? btrfs_commit_transaction+0x46/0x960 [btrfs]
Oct 19 07:19:54 fatblock kernel: [210309.372112]  ? start_transaction+0x89/0x410 [btrfs]
Oct 19 07:19:54 fatblock kernel: [210309.372698]  ? transaction_kthread+0x195/0x1b0 [btrfs]
Oct 19 07:19:54 fatblock kernel: [210309.373278]  ? kthread+0xfc/0x130
Oct 19 07:19:54 fatblock kernel: [210309.373862]  ? btrfs_cleanup_transaction+0x520/0x520 [btrfs]
Oct 19 07:19:54 fatblock kernel: [210309.374446]  ? kthread_create_on_node+0x70/0x70
Oct 19 07:19:54 fatblock kernel: [210309.375052]  ? ret_from_fork+0x25/0x30
Oct 19 07:19:54 fatblock kernel: [210309.375630] Code: 56 8b 44 24 70 49 89 d9 4c 89 e1 4c 89 fe 48 89 ef 50 41 55 4c 8b 44 24 68 48 8b 54 24 20 e8 2f d7 ff ff 48 83 c4 18 31 c0 eb b0 <0f> 0b e8 f0 7d 47 eb 0f 1f 44 00 00 41 57 41 56 49 89 f7 41 55 
Oct 19 07:19:54 fatblock kernel: [210309.376874] RIP: insert_inline_extent_backref+0xd9/0xe0 [btrfs] RSP: ffffbaa64a3b3bf0

Weiß jemand Rat?

[Colttt]

Hallo Mischi,

das erste btrfs problem scheint aber nichts mit der letzten Meldung zu tun haben, da dort btrfs nicht meckert.. zumal du eigentlich ein 'btrfs scrub start /' hättest machen können, das Problem hätte sich dann bestimmt selbst gelöst..

Solltest du evtl jetzt auch machen und danach ein balance.. du nutzt raid1 richtig auch snapshots? Wenn ja lösch mal diese und guck ob der fehler weiterhin auftritt, wenn ja bin ich raus, müsstrst du dann mal auf der ML von btrfs fragen

[mischi]

Ein btrfs scrub hatte ich gemacht nach dem reboot:

Code: Alles auswählen

[ 7803.099614] BTRFS warning (device sdf1): checksum error at logical 884838899712 on dev /dev/sdf1, sector 1733460240, root 5, inode 708093, offset 7393280, length 4096, links 1 (path: backup/backuppc/cpool/9/1/7/9177f2e4c30d4b245eff4dce6003e76e)
[ 7803.099853] BTRFS error (device sdf1): bdev /dev/sdf1 errs: wr 0, rd 0, flush 0, corrupt 1, gen 0
[ 7803.099939] BTRFS error (device sdf1): unable to fixup (regular) error at logical 884838899712 on dev /dev/sdf1

Ich nutze kein raid1 mit einer anderen Platte. Das Filesystem ist frisch angelegt und hat noch keine Snapshots. Insofern schon komisch, das der scrub schon wieder Fehler meldet. Irgendwie vermute ich da doch einen HW Fehler.

[smutbert]

Das (einen Hardwarefehler) würde ich auch vermuten.

Es wäre imho schon sehr beunruhigend wenn, noch dazu gehäuft solche Prüfsummenfehler auftauchen ohne dass die Hardware schuld ist, zB eben der Haupzspeicher oder bei in den SMART-Informationen die Zahl der nicht korrigierbaren Fehler und/oder der fehlerhaften Blöcke nach oben geht.

Ich hab z. B. eine externe Festplatte, die momentan knapp 100 logische Volumes, davon mehr als 80 Snapshots enthält, auf der aktuell beim täglichen Backup 4 readonly-Snapshots und daneben noch ein paar weitere Daten dazukommen, die ich obendrein irrtümlich schon desöfteren im gemounteten Zustand abgesteckt habe und die auch schon in Betrieb war, während ich fiese USB-Probleme hatte und trotzdem sind alle Prüfsummen in Ordnung und nach einigen Meldungen über fehlerhafte "free space caches" scheint auch das Dateisystem komplett in Ordnung zu sein (ich habe unabhängig von den Prüfsummen von btrfs die Korrektheit eines Großteils der Daten überprüft, bei meiner Musiksammlung zum Beispiel mit den in den flac-Dateien eingebauten Prüfsummen).

[Colttt]

Ok, dann +1 für kaputte festlatte/kabel/ram

Memtest für 1tag laufen lassen ohne fehler?

[scientific]

Also meine externen Platten mit btrfs reagieren leider äußerst empfindlich auf Abstecken im gemounteten Betrieb... Musste ich schon ein paar Mal neu formatieren, weil das btrfs unreparierbar kaputt war.

Mit neueren Kerneln tritt das jedoch deutlich seltener auf.

[nudgegoonies]

Sind die Probleme, die es in der Kombinations btrfs und Kernel 4.11 gab mit 4.12 völlig behoben? https://wiki.debian.org/Btrfs#Status

Ich hatte mir überlegt wegen der Prüfsummen (die ganzen anderen Features brauche ich nicht) für die demnächst anstehende Debian 9 Installation auf btrfs zu wechseln. Aber COW und das SSD Verhalten, kein Trim, solche Fehler wie aus dem Link und dass man soll kein overlayfs verwenden soll halten mich nun doch davon ab.

[smutbert]

Diese Wiki-Seite hatte ich bis jetzt gar nicht auf dem Radar und ich muss zugeben, dass ich mich an erschreckend wenige der dortigen Empfehlungen halte.

Ich verwende zum Beispiel auf USB-Sticks durchaus compress=lzo und auf einer SSD sowohl die Mountoption autodefrag wie auch discard und habe dort keinerlei Overprovisioning aktiviert (und auch keinen auf anderem Wege stillgelegten, also zum Beispiel unpartitionierten Bereich). Speziell auf meinem Backuplaufwerk gibt es außerdem eindeutig Snapshots von mindestens vier Subvolumes als dort empfohlen werden.

Lediglich der Empfehlung quotas und raid5/6 nicht zu verwenden folge ich.

Zu 4.11 kann ich nicht viel sagen - die Version gibt es nicht (mehr?) in Debian - bis 4.9 habe ich jedenfalls nichts von Problemen bemerkt und die nächste Version, die ich installiert habe, das ist 4.12 aus den Backports, lief soweit ich das sagen kann auch einwandfrei - inzwischen läuft bei mir das aktuelle 4.13 aus den Backports und die kurze Zeit, die das läuft, gab, es auch keine Probleme.

Ich muss zugeben, dass, hätte ich von allen dort erwähnten Problemen gewusst, vermutlich nicht auf btrfs umgestiegen wäre, aber nun nutze ich es schon so lange zu meiner vollsten Zufriedenheit, dass deutlich verheerendere Schwierigkeiten bekannt werden müssten, damit ich mich wieder davon abwende.

[scientific]

Ich war auch sehr erstaunt was mir alles für Probleme drohen...

Einzig bemerkte ich, dass mein Bachuptool mit 4.13 versagte. Als ich dem auf den Grund ging, bemerkte ich eine Änderung des Formats in der Ausgabe von

Code: Alles auswählen

 btrfs subvol list

Der Fieldseparator von einem space funktionierte nicht mehr, da die uuid-Felder wenn sie nich vorhanden sind, mit Leerzeichen aufgefüllt werden. Leider ist das nich konsequent durchgezogen, dass ich mich auf fixe Feldbreiten oder einen Fieldseparator von einem Space verlassen kann...
Muss noch einen Bugreport verfassen.
Aber von den beschriebenen Problemen hab ich bis jetzt lediglich die kaputten Quotas verifiziert.

Lg scientific

[nudgegoonies]

Danke für eure Erfahrungen. Ich habe letztens einen Arbeitsrechner mit BTRFS und Stretch aufgesetzt und der Installer bot mir bei den Mountoptionen discard gar nicht erst an. Bei ext4 konnte man es direkt im installer auswählen. Vielleicht überlege ich es mir ja noch. Ubuntuusers liest sich übrigens noch viel schlimmer als das Kernel Wiki. Aber da ist ja einiges noch auf dem Stand von Ubuntu 12.04. Im Kernel Wiki sind auch sehr viele hilfreiche interne Subseiten zu btrfs verlinkt.

[wanne]

Also kaputte Checksummen, sind ja sollche fehler, die die Festplatte nicht erkennt. Das SMART da nicht meckert und das kopieren ohne Überprüfung ob de Daten auch unverändert sind ist nicht weiter verwunderlich.
Würde auf ein kaputtes SATA-Kabel tippen. Aber nur so ein gefühl.

[nudgegoonies]

Eines steht schon mal fest, es geht nichts über Prüfsummen.

Ich habe ECC Speicher und ich will nach schlechten Erfahrungen mit Bitkippern in wichtigen Dateien und undefinierbaren Abstürzen auch nie wieder einen Rechner ohne ECC Speicher haben.

Ich dachte aber, dass das SATA Protokoll, USB Protokoll und die Festplattencontroller in der Low-Level Formatierung selber Prüfsummen haben die so gut sind, dass Bitkipper wegen schlechter Kabel beim Storage ausgeschlossen wären.

Für mich klingt es jetzt so, das mein nächstes Dateisystem bei der Installation von Debian 9 BTRFS werden muss. Zumindest wenn ich mir die anderen Filesysteme anschaue, die Prüfsummen für Meta- und Nutzdaten unterstützen (ZFS, NILFS, GPFS, NOVA, BeeGFS), scheint mit BTRFS für den Alltagseinsatz das robusteste und verbreitetste zu sein: https://en.wikipedia.org/wiki/Compariso ... s#Metadata Und darauf warten, dass EXT4 endlich nachzieht will ich auch nicht.

[owl102]

Ich dachte aber, dass das SATA Protokoll, USB Protokoll und die Festplattencontroller in der Low-Level Formatierung selber Prüfsummen haben die so gut sind, dass Bitkipper wegen schlechter Kabel beim Storage ausgeschlossen wären.

Wenn z.B. der USB-Controller des PC (oder des USB-Sticks) defekt ist, hilft es überhaupt nicht, wenn die eigentliche Übertragung via USB gesichert ist. Die einzige Methode, um wirklich die Datenintegrität sicher zu stellen, ist, die Daten selber zu überprüfen, was logischerweise weder SATA, USB oder der Festplattencontroller können. Die können nur annehmen, daß die Daten, die sie zum Senden bekommen, korrekt sind. Davon ab ist auch die Übertragung via SATA usw. nicht mehr so sicher wie früher. AFAIK kann bei SATA im Durchschnitt pro 4TB Daten ein Bitfehler unentdeckt bleiben. Vor Jahren war das völlig akzeptabel, heutzutage ist das bei großen Storage Systemen ein Problem, welchem in der Regel mit ZFS begegnet wird.

Und wer denkt, das dies nur theoretische Probleme sind: Mir hat mal ein defekter USB-Controller reichlich Dateien zerschossen. Mit btrfs (oder ZFS) auf der externen USB-Platte wäre das nicht passiert.

[wanne]

Ich dachte aber, dass das SATA Protokoll, USB Protokoll und die Festplattencontroller in der Low-Level Formatierung selber Prüfsummen haben die so gut sind, dass Bitkipper wegen schlechter Kabel beim Storage ausgeschlossen wären.

Hat SATA Checksummen?
Ich kann auf jeden Fall sagen, dass ich schon probleme mit korrupten Daten hatte, und das austauschen des SATA-Kabels das behoben hat.
Und das war eher nicht im TB-Berich Daten. Würde mich wundern, wenn da Checksummen drauf wären.
Vielleicht war es aber auch nur ein billiger Controller, der die nicht geprüft hat.

[nudgegoonies]

Wenn z.B. der USB-Controller des PC (oder des USB-Sticks) defekt ist, hilft es überhaupt nicht, wenn die eigentliche Übertragung via USB gesichert ist. Die einzige Methode, um wirklich die Datenintegrität sicher zu stellen, ist, die Daten selber zu überprüfen, was logischerweise weder SATA, USB oder der Festplattencontroller können. Die können nur annehmen, daß die Daten, die sie zum Senden bekommen, korrekt sind. Davon ab ist auch die Übertragung via SATA usw. nicht mehr so sicher wie früher. AFAIK kann bei SATA im Durchschnitt pro 4TB Daten ein Bitfehler unentdeckt bleiben. Vor Jahren war das völlig akzeptabel, heutzutage ist das bei großen Storage Systemen ein Problem, welchem in der Regel mit ZFS begegnet wird.

Und wer denkt, das dies nur theoretische Probleme sind: Mir hat mal ein defekter USB-Controller reichlich Dateien zerschossen. Mit btrfs (oder ZFS) auf der externen USB-Platte wäre das nicht passiert.

Ok,es reicht. Meine Backupplatten habe ich schon mal umgestellt. Die Umstellung geht voran.

Hat SATA Checksummen?
Ich kann auf jeden Fall sagen, dass ich schon probleme mit korrupten Daten hatte, und das austauschen des SATA-Kabels das behoben hat.
Und das war eher nicht im TB-Berich Daten. Würde mich wundern, wenn da Checksummen drauf wären.
Vielleicht war es aber auch nur ein billiger Controller, der die nicht geprüft hat.

Ich habe mir mal die SMART Werte meiner Platten angeschaut und es gibt tatsächlich einen Counter, der Übertragungsfehler mitzählt. Heißt aber je nach Platte unterschiedlich. Einmal "Hardware_ECC_Recovered", einmal "UDMA_CRC_Error_Count" und einmal beides. Es kommt natürlich auf den CRC bzw. ECC Algorithmus an, wie viele Bitskipper erkannt und korrigiert, wie viele Bitkipper und erkannt und nicht korrigiert und wie viele gar nicht erkannt werden können. Prinzipiell ist SATA also abgesichert. Aber wenn Algorithmus und Kabel schlecht sind gute Nacht. Ein kaputter Controller, der anderweitig noch Bitkipper produziert ist natürlich totale eine Katastrophe.

P.S.
"End-to-End_Error" gibt es auch noch in SMART. Muss mir mal anschauen was die 3 genau bedeuten.

[nudgegoonies]

Jetzt läuft bei mir alles unter btrfs. Auch die root Partition. Aber erst nachdem ich die Option remount-ro in der fstab entfernt hatte, die dafür sorgte, dass die root Partition im Vergleich zu ext4 nur lesend eingebunden wurde. Typischer Anfängerfehler von mir als ich nach dem rsync Hin- und Her in der fstab nur das ext4 durch btrfs ersetzt habe.

Da ich viele Features ja gar nicht nutze (RAID, Volumes, Snapshots, Compression, ich mounte einfach nur mit noatime,nodiratime) bleibt eigentlich nur noch die Frage nach discard und autodefrag. Schlimm, wie sich da alle Wikis zwischen Debian, Kernel und Ubuntuusers unterscheiden.

Ich verwende [...] auf einer SSD sowohl die Mountoption autodefrag wie auch discard und habe dort keinerlei Overprovisioning aktiviert (und auch keinen auf anderem Wege stillgelegten, also zum Beispiel unpartitionierten Bereich).

Warum nutzt Du autodefrag auf einer SSD? Das normale Defragmentieren sorgt auf rotierenden Festplatten ja dafür, dass alle Blöcke einer Datei hintereinander auf der Platte liegen damit der Lesekopf beim linearen Lesen nicht hin- und herfahren muss. Aber bei SSDs sind solche Optimierungen ja irrelevant. Laut Ubuntu Wiki schaltet die Option SSD die Optionen autodefrag und space_cache ab. Stimmt aber nicht. Bei mir wird die Option SSD auf der SSD ohne das ich es angebe gesetzt und space_cache ist automatisch eingeschaltet.

Bei autodefrag widerspricht sich das Debian Wiki sogar selber. Einerseits sollen discard und autodefrag "buggy behavior" haben und an anderer Stelle wird autodefrag explizit empfohlen. Ich glaube ich lasse beides einfach weg. Auf der SSD ist genug Platz und ich trimme einfach täglich und defragmentiere die rotierende Platte einfach wöchentlich.

P.S.
Alles ist natürlich immer noch nicht mit Prüfsummen gesichert - GRUB und die SWAP Partition sind immer noch ohne - wobei nur SWAP Auswirkungen auf den laufenden Betrieb hat.

[smutbert]

Dass autodefrag vermutlich nicht viel Sinn hat, gebe ich gerne zu, andererseits profitieren glaube ich durchaus auch SSDs davon, wenn die Daten/Dateien in einem Stück geschrieben und gelesen werden können, auch wenn es nur um die logische Zuordnung der Speicherblöcke und nicht die eigentlichen Speicherzellen geht.
Es hat also eventuell keinen Vorteil, aber ich habe auch nicht beobachtet, dass durch autodefrag das Schreibvolumen auf die SSD merkbar ansteigen oder die Schreibperformance sinken würde.

Wahrscheinlich würde ich sogar eher discard rausnehmen und stattdessen selbst trim ausführen, denn da meine ich tatsächlich einen Geschwindigkeitsunterschied zu spüren...

[nudgegoonies]

Dann werden dadurch nicht nur Blöcke defragmentiert sondern auch Metadaten optimiert?

Hier liest es sich wieder so, als ob man "moderne" SSD völlig anders nutzen soll :
https://btrfs.wiki.kernel.org/index.php ... unt_option

[smutbert]

Keine Ahnung ob es auch Metadaten defragmentiert – an vielen Stellen habe ich in dem Zusammenhang vom Defragmentieren der Verzeichnismetadaten und Daten ("folder metadata and file contents") gelesen, aber ein generelles und eigentlich das größte Problem, das ich mit btrfs habe, ist, dass ich selten weiß wie alt, aktuell oder zutreffend irgendeine Behauptung, ein Wiki oder ein Bruchstück einer Dokumentation nun eigentlich ist.

(Abgesehen von den paar Dingen natürlich, deren Entwicklung man fast schon zwangsläufig mitbekommt, wenn man btrfs eine Zeit lang verwendet und sich, ebenfalls zwangsläufig, ein bisschen damit auseinandersetzt.)