Diskussion:Btrfs

Fedora 17 wird doch btrfs nicht als standard Dateisystem verwenden

Da meine Änderung verworfen wurde hier nochmal die Quelle: http://www.heise.de/open/meldung/Fedora-verschiebt-Einsatz-von-Btrfs-abermals-1436535.html Dadurch wird überhaupt die Erwähnung von Fedora irrelevant.

16:42, 17. Feb. 2012 (CEST)

Sry, habe erst jetzt gesehen, dass sie noch nicht gesichtet wurde

16:47, 17. Feb. 2012 (CEST) (ohne Benutzername signierter Beitrag von 213.33.13.166 (Diskussion) )

Anglizismen oder nicht

Wer bitte verwendet solche Ausdrücke wie "Schnappschüsse", wo Snapshot doch jedem geläufig ist? Die Hauptentwicklungsgruppen aus dem Bereich der IT kommen aus dem angloamerikanischen Raum, auch wenn vielleicht viele noch einem Zuse nachtrauern. Ansonsten können wir direkt damit beginnen "Link" als Verweis einzudeutschen ;-) 80.137.217.170 00:13, 30. Okt. 2010 (CEST)

Natürlich sollten Anglizismen hier – in unserer heimat-/deutschsprachigen Wikipedia – wenn immer möglich vermieden werden. Und um deine vermutlich nur rhetorisch gemeinte Frage dennoch zu beantworten: Ganz einfach, normale Leute die noch nicht verlernt haben, unsere gute Heimatsprache zu sprechen und die Menschen die noch nicht durch die auch in Deutschland propagierenden amiüberfreundlichen Medien gehirngewaschen wurden und daher noch (oder wieder) in der Lage sind, Deutsch von Englisch sowie anderen Fremdsprachen zu unterscheiden. Der „Schnappschuss“ (oder in der Mehrzahl die „Schnappschüsse“) ist nun einmal die wörtliche Übersetzung dieses Fremdwortes. Übrigens wären (die) „Momentaufnahme“ (so wie es im Allgemeinen ja eigentlich auch jedes Ab-/Bild ist) oder eben (etwas genauer) das „Speicherabbild“ auch zwei (je nach Zusammenhang) passende Übersetzungen. Zudem ist es kein unveränderliches Naturgesetzt, daß Informationstechniken hauptsächlich aus Amiland kommen. Im Gegenteil, diese Aussage kann sogar stark bezweifelt werden, so wie die Ansicht von vielen IT-geschädigten Menschen (dessen Ursache sehr wahrscheinlich der Konsum nicht oder nur magelhaft übersetzter oder lokalisierter Programme ist), die meinen (und das auch anscheinlich bei jeder Gelegenheit propagieren müssen), daß der anglizistische „Link“ (oder in der Mehrzahl die „Links“) im deutschen Sprachraum angeblich bekannter ist als etwa der (Quer-)Verweis oder die Verknüpfung. Mit freundlichen Grüßen aus der Heimat, 92.229.53.195 08:11, 24. Feb. 2012 (CET) (CET) (MEZ)!

Ahja. Ich finde "Link" und "Snapshot" sind in diesem Kontext aber die schöneren Wörter...

134.245.202.67 02:15, 14. Mär. 2013 (CET)

Meine unscheinbare Meinung (ja, ich bin noch nicht mal eingeloggt gerade ...): "Link" ist tatsächlich überall etabliert, aber Snapshot kennt der gemeine DAU nicht, der kann sich unter Schnappschuss schon eher was vorstellen. Und das Wort klingt auch völlig in Ordnung und wird sogar verwendet ... ;) --185.76.96.208 20:50, 5. Nov. 2016 (CET)

dateiname

seid ihr sicher mit den 255 zeichen dateinamen? das halte ich für ein modernes verzeichniss für ganz schön wenig, nud ich hätte auf meinem system sogar dateien die drübergehn... (nicht signierter Beitrag von 217.11.197.10 (Diskussion | Beiträge) 19:15, 29. Jan. 2010 (CET))

Die üblichen Dateinamenlängen unter Linux kann man per "getconf NAME_MAX /" und "getconf PATH_MAX /" abfragen. Diese sind in der Tat bei nahezu allen Dateisystemen unter Linux für den Dateinamen 255 und für den Pfad 4096 Zeichen lang. --PowerGFX (Diskussion) 11:16, 6. Nov. 2014 (CET)

Ich war auch gerade überrascht. Habe einen neuen Rechner aufgesetzt, wollte btrfs eine Chance geben - jetzt hab' ich aber Probleme, die Dateien von einem ext4 rüberzukopieren, eben wegen dieser Beschränkung (gleich mal den Artikel hier gelesen, weil das doch etwas überraschend kommt für ein Dateisystem neueren Datums) ... Da sollten die btrfs-Jungs unbedingt noch mal drüber gehen ;) Aber gut, ich beschwere mich nicht, bei ext4 sind ja direkt nach der Formatierung schon mal ein paar GB belegt für Verwaltungsinformationen ... --185.76.96.208 20:50, 5. Nov. 2016 (CET)

Löschwut

Wieso soll das gelöscht werden? Ich habe danach gesucht und war froh die informationen hier zu finden. Ich habe schon davon gehört das einige in der deutschen Wikipedia radikal am Artikel löschen sind. Muss ich also in Zukunft auch auf die englische Wikipedia ausweichen wenn es um Artikel geht die irgendwelche einzelnen Leute für "überflüssig" halten?

Die Entwicklung von Btrfs ist sicher sehr interessant für viele Open-Source-User. Ich halte diesen Artikel für alles andere als überflüssig! --L3u 11:36, 26. Jul. 2008 (CEST)

Da sich Btrfs in Zukunft wohl zum de facto Standard-Dateisystem für Linux-Distributionen im Desktop-Bereich entwickeln wird (bzw. könnte) sollte eine Löschung nicht zur Debatte stehen ! Weiters vereinigt es einige innovative und nötige Neuerungen in sich selbst. Was ist bloß los mit dieser Löschwut in der deutschen Wikipedia ? --Medwikier 16:58, 30. Dez. 2009 (CET)

Bitte guck mal auf das Datum des obigen Eintrags, anstatt einen Rundumschlag gegen die angebliche Löschwut zu starten. Der obige Eintrag stammt von Mitte 2008. Damals gab es einen Antrag, der aber eindeutig abgelehnt wurde, obwohl BTrfs damals noch rein experimentell war. --Olenz 17:21, 30. Dez. 2009 (CET)

---

Hallo! Hatte eben auf der Homepage von OpenSuse gelesen, das Btrfs in die neue Entwicklung OpenSuse 11.2 aufgenommen wurde bzw. mit YaST als Partition eingerichtet werden kann. Das habe ich eben hinzugefügt und hoffe, mit dem Einzelnachweis alles richtig gemacht zu haben. Habe da ein bisschen herumexperimentiert, doch ich denke, so ist das Ergebnis angemessen. --Markuqui 14:41, 10. Nov. 2009 (CET)

btrfs und plattenplatz

wo hast du das im mail-thread gesehen, dass es endgültig gelöst ist? siehe zb http://article.gmane.org/gmane.comp.file-systems.btrfs/7108/match=enospc, http://article.gmane.org/gmane.comp.file-systems.btrfs/8445/match=enospc+2011 --ThurnerRupert 22:10, 10. Jan. 2011 (CET)

Diese Zeilen:

>> They are the ENOSPC fixes, as well as fixes for df command.

>> The first one and the last one fixed the wrong free space information reported

>> by df command. The second one fixed ENOSPC when there is tiny space in the

>> filesystem. And The third fixed wrong calculation of stripe size. And the 4th

>> and 5th patches fixed the chunk allocation problem when the block devices have

>> no enough space to allocate a default-size chunk.

verstehe ich so.

sowie die Aussage:

"..ENOSPC handling of volume management operations, completing the -ENOSPC support"hier.

Deine Quellen beschreiben den Fehler, sind aber alle aus dem Juni, während die oben zitierte Mail vom Januar 2011 und das Changelog aus dem August 2010 stammt.

Wie kommst Du wiederum darauf, das Problem sei noch nicht gefixt?

Hast Du eine Quelle, die neuer ist als August 2010, die das immer noch behauptet ? --hg6996 06:20, 11. Jan. 2011 (CET)

Nachtrag: Wie ich gerade sehe, gibts offenbar seit heute ein brandneues Release 2.6.37, lassen wir uns mal überrachen, wie das Changelog in den nächsten Tagen (oder Stunden?) aussehen wird ! --hg6996 08:45, 11. Jan. 2011 (CET)

Benutzbarkeit

Btrfs wird seit 2007 entwickelt und jeder weiß, daß man ein Dateisystem erst dann als für die ernsthafte Nutzung ausreichend zuverlässig bezeichnen kann, wenn es ein Alter von 8-10 Jahren erreicht hat. Dies ist übrigens eine empirische Erfahrung, die z.B. mit dem UFS (Entwicklungsbeginn 1981) gemacht wurde. Btrfs könnte also frühestens ab ca. 2015 den Zustand der ernsthaften Benutzbarkeit erreichen.

Die Entwicklung von ZFS wurde im Jahre 2001 begonnen. Daher hat ZFS seit Kurzem den Status der ernsthaften Nutzbarkeit erreicht.

Bei Btrfs sieht es aber sogar so aus, als ob noch nicht einmal die Designfehler beseitigt wurden. Wenn man nach btrfs broken by design sucht, findet man zahlreiche Ergebnisse, z.B. http://lwn.net/Articles/393144/

Sollte daher nicht auch zumindest ein Abschnitt zum Thema Benutzbarkeit in den Artikel? Dies erscheint gerade jetzt sinnvoll, denn morgen (am 14.1.2011) wird die Fertigstellung der ZFS-Integration in den Linux-Kernel angekündigt werden. --Schily 11:28, 13. Jan. 2011 (CET)

Ist eine solche Aussage (8-10 Jahre Reifungszeit) wirklich so pauschal möglich ? HPFS bzw. NTFS waren doch deutlich schneller entwickelt - oder etwa nicht ? --hg6996 11:26, 14. Jan. 2011 (CET)

Es lohnt sich mal HPFS zu lesen ;-) Auch NTFS war in den ersten 10 Jahren alles andere als ein zuverlässiges Filesystem. --Schily 12:54, 14. Jan. 2011 (CET)

Nun, im Lemma HPFS fand ich nix, was auf fehlendes Stabilität hinwies, das Fehlen eines Journals ist per se ja nichts was gegen seine Benutzbarkeit spräche. Dass NTFS in den ersten 10 Jahren unzuverlässig war, ist mir persönlich neu. Ich frage mich außerdem: Wenn wir hier in das Lemma etwas über die Benutzbarkeit schreiben, so müsste das auch in anderen Lemmata geschehen. Gibts denn Quellen, die sich über die Ausgereiftheit von Dateisystemen äussern ? --hg6996 14:22, 14. Jan. 2011 (CET)

Ach, Hauptsache ist nur, dass der Hauptautor nicht wegen Mordes ins Gefängnis muss ... Stichwort ReisswolfFS aka. ReiserFS. Ansonsten scheint es einfach zum einen in den bestehenden Dateisystemen (inkl. ext4 und Schilys heiligem ZFS) gewisse andere Defizite zu geben. Und dass btrfs so schnell so weit (und in den Kernel) gekommen ist - reiserFS hat da, wenn ich mich erinnere, Jahre gebraucht - könnte daran liegen, dass es vielleicht eine sehr kompetente und große Entwicklergemeinde dazu gibt. Aber, lieber Schily: als bekannter Solaris-Evangelist möchte ich bitten dich aus solchen Diskussionen herauszuhalten. Du bist nicht neutral, sondern voreingenommen (was dich leider meistens auch noch zu einem sehr unangenehmen Gesprächspartner macht!) --87.174.103.229 18:09, 15. Jan. 2011 (CET)

P.S. der Artikel schreibt im ersten Absatz ist daher nicht für den Einsatz in Produktionsumgebungen gedacht und experimentellen Betrieb - ich finde das reicht aus, der Artikel sagt schon mehr als deutlich dass es noch nicht fertig ist! Also insbesondere bitte keine ZFS-Werbung hier einbauen ... --87.174.103.229 18:09, 15. Jan. 2011 (CET)

Wie ermöglicht es so große Dateien?

Hallo, laut dem Inode Artikel ist es maximal möglich, dass eine Datei 4 TiB groß sein kann. Btrfs scheint auch Inodes zu verwenden kann aber bis zu 16 EiB große Dateien besitzen? Sind die Blöcke einfach so groß wählbar? Wobei die Blöcke mehr als 4 Millionen mal so groß wären. --xZise 13:23, 9. Okt. 2011 (CEST)

Das Beispiel in dem Artikel bezieht sich nur auf ext2. In btrfs werden die Blockadressen nicht zusammen mit der Inode gespeichert, sondern in einem extra Baum (als Extents). Deswegen ist die maximale Dateilänge nicht durch den Speicher begrenzt, der für die Blockzuordnung zur Verfügung steht, sondern nur durch die Breite des Dateilängenfelds (16 Exabyte = 2^64 => 64 Bit). --Schuetzm 14:40, 17. Okt. 2011 (CEST)

Okay das klingt logisch. Nur zum Verständnis: Im Inode selber steht dann nur noch wo die Wurzel des Baums ist. Von da aus kann man man sich durch hangeln und den entsprechenden Block suchen. --xZise 19:06, 27. Okt. 2011 (CEST)

Abschnitt Geschichte...

sollte mal von jemanden Korrektur gelesen werden. Engl. Satzbau, Gedankenstriche statt Komata, Groß- & Kleinschreibung usw.---95.91.58.72 17:55, 9. Feb. 2012 (CET)

Distributionen

Zitat aus dem Artikel: "Bei einigen Linux-Distributionen steht das Dateisystem bereits offiziell bei der Installation zur Auswahl." Gibt es dafür eine Quelle mir ist nämlich keine entsprechende Distribution bekannt. --79.224.255.13 22:06, 13. Mär. 2012 (CET)

Archlinux, Gentoo, openSUSE um nur mal 3 zu nennen Vamp898 (Diskussion) 09:22, 24. Jul. 2012 (CEST)

Stand aktualisiert

Auch wenn Fedora das bereits integriert, aktueller Stand ist das btrfs keine Stable ist.

Zitat von der btrfs Homepage: "Btrfs is under heavy development, but every effort is being made to keep the filesystem stable and fast. Because of the speed of development, you should run the latest kernel you can (either the latest release kernel from kernel.org, or the latest -rc kernel."

Hab also mal aktualisiert das es aktuell immer noch keine stable gibt und den "Veraltet" hinweis wieder entfernt.

Vamp898 (Diskussion) 09:22, 24. Jul. 2012 (CEST)

Auch meine Frage dazu: im Abschnitt "Kritik am Design" wird auf Quellen von vor einigen Jahren verwiesen. Bestehen diese Kritikpunkte noch? Wie "stable" ist das Dateisystem inzwischen? Danke schonmal im Voraus. --84.159.218.44 21:23, 8. Feb. 2015 (CET)

Btrfs weist zahlreiche Gemeinsamkeiten mit ZFS auf. ???

Bitte welche? Ich habe im Internet gelesen, dass z.B. ein Spiegel generell wie ein RAID0 genutzt würde und man BTRFS erst erklären müsste, ob eine Datei mit oder ohne Redundanz geschrieben werden soll (leider kein Link). In ZFS gibt es zwar auch die Möglichkeit "zfs set copies=#", also die Anzahl der Kopien einer Datei, aber man definiert zuvor den Pool und damit auch die Redundanz verbindlich. Welcher Sinn möglicherweise Vorteil liegt dann in einem RAID0 Verhalten von BTRFS?

All diese Optionen werden Anwender eher verwirren, zudem halte ich BTRFS von den Befehlen her teils für recht kryptisch im Vergleich zu ZFS. Der Anwender hat zudem keine verlässliche Größe seines BTRFS Speichers. Wenn es schon beim Spiegel (RAID1) kaum gemeinsames gibt, wie sieht es dann bei RAID 5/6 und Trible RAID aus?

Bitte erklärt die ZFS Gemeinsamkeiten/Unterschiede genauer, Danke! (nicht signierter Beitrag von SchaubFD (Diskussion | Beiträge) 21:43, 28. Sep. 2015 (CEST))

@SchaubFD: erstmal: BTRFS hat einige optionen, die auf eine datei oder einen ordner bezogen werden können. mit "chattr +C $DATEINAME" würdest du z.b. copy on write für diese datei abschalten, sofern diese noch leer ist (ansonsten muss sie neu geschrieben werden). irgendwo wurde auch mal die idee angetragen, bei RAID leveln für dateien und ordner festzulegen, ob diese überhaupt gespiegelt werden sollen (z.b. temporäre dateien unter /tmp). dies ist allerdings noch nicht implementiert. ansonsten ist die RAID unterstützung wie erwartet, die ganze platte wird gespiegelt. siehe auch. die größen gemeinsamkeiten hab ich mal vermerkt. der artikel müsste aber noch ein bisschen überarbeitet werden, damit eine rote linie reinkommt. heut aber nicht mehr --nicht der schonwieder(tm) 22:55, 1. Okt. 2015 (CEST)

Btrfs wird ext4 ersetzen?

Im ersten Abschnitt steht "In Zukunft wird Btrfs das bislang im Linux-Umfeld vorherrschende ext4-Dateisystem ersetzen, da dieses nur einen Teil der Beschränkungen von ext3 wie Dateigröße und Gesamtdateisystemgröße aufgehoben hat.". Ist das wirklich so? Gibt es dafür einen Beleg? --Noresoft (Diskussion) 18:42, 9. Jun. 2016 (CEST)

Nachdem bis jetzt noch nichts von einem ext5 zu sehen ist, wird das wohl auch keiner mehr starten in Anbetracht der Konkurrenz. Und btrfs hat einige nette Features, die ext4 noch lange nicht hat. Copy-on-Write wird die Zukunft sein, das ist ein ähnlicher Schritt wie damals die Einführung von Journalen. --185.76.96.208 20:50, 5. Nov. 2016 (CET)

Läuft wohl auch auf Synologys NAS-Systemen

Wird wohl auch auf Synologys NAS-Systemen, im Zusammenhang mit deren sogenanntem Disk Station Manager (oder kurz DSM), genutzt – wobei Letzterer (also dieser oder auch [geschlechslos] dieses DSM anscheinlich eine Linux- oder BSD(?)-Spielart, oder allgemeiner [und damit wohl sicherer] irgendwas Unixähnliches, sehr sicher aber wohl [ähnlich wie das FritzOS] ein sogenanntes „[NAS- und Router-]Betriebssystem“ ist).
Siehe auch:

• DSM 6.1: Synology bringt Btrfs auf mehr alte NAS-Systeme – Golem, am 22.2.2017
• SRM 1.1: Erstes großes Update für Synologys Routerbetriebssytem – Golem, am 19.7.2016

-- 4osuvfa, am 8.3.2017, 07:47 (MEZ)

Synology DSM ist ein Linux.^Link Daher kann es natürlich auch btrfs und alles andere, was Linux zu bieten hat. Man kann ja auch mit optware bzw. ipkg zusätzliche Linux-Software installieren.^Link Außerdem ist der Zugang auf den Terminal bzw. die Konsole (wie immer man es nennen möchte) per ssh und telnet, wenn aktiviert, möglich. Das geht auch unter Windows, etwa mit PuTTY.^Link ‣Andreas•⚖ 03:53, 16. Aug. 2017 (CEST)

journaling

wird im Artikel nicht erwähnt, auch nicht, dass daraus resultierende viele zusätzliche Schreibzugriffe gegenüber anderen FS nicht so gut ist für SSDs.--Mideal (Diskussion) 12:11, 15. Aug. 2017 (CEST)

Der Linux-Kernel aktiviert automatisch Optimierungen für SSD, wenn eine erkannt wird. Auch TRIM/discard wird automatisch aktiviert.^Link Aber natürlich ist ein auf Flash optimiertes Dateisystem besser, auch wenn es dann kein Journal verwenden sollte. ‣Andreas•⚖ 04:04, 16. Aug. 2017 (CEST)

Btrfs ist bald tot

Das Dateisystem ist fast tot. Red Hat hat es kürzlich als obsolet deklariert. Es wird nicht der Nachfolger von ext4 werden. SUSE unterstützt es noch und sagt auch, dass es weiter unterstützt wird. Wir werden sehen. Alle anderen Distributionen nehmen es nicht als Standarddateisystem. Bevor hier ein Edit-Krieg ausbricht wüsste ich gerne, ob es jemanden gibt, der das anders sieht, da ich den Artikel gerne dahingehend bearbeiten möchte. --Raumhafen (Diskussion) 14:29, 23. Okt. 2017 (CEST)

Ähm bitte was?

RedHats Probleme beruhen auf der extrem veralteten Kernel Version von RHEL. Dort wird aktuell noch Linux Kernel 3.10 eingesetzt, das heisst das btrfs in RedHat ist auf dem Stand von vor über 5 Jahren.

Das ist kein Maßstab für die Zuverlässigkeit, Qualität oder Zukunftssicherheit von btrfs, außerdem hat RedHat keine Alternative dafür.

ext4 kann weder deduplizierung, noch transparente Kompression oder andere Features welche bei Windows und anderen UNIX Systemen (Solaris, BSD) seit Jahren Standard sind.

btrfs wird der nachfolger von ext4 sein, ob RedHat da mitzieht ist relativ egal und ein Todesurteil für btrfs ist das noch lange nicht. --213.95.169.180 17:45, 26. Jun. 2018 (CEST)

Vor allem: Red Hat ist nicht der Nabel der Linux-Welt. So lange Debian btrfs aktiv unterstützt, ist der Patient noch lange nicht im Grab. ---<)kmk(>- (Diskussion) 22:41, 18. Dez. 2018 (CET)

Außerdem ist RedHat auf Server ausgelegt. Die haben vielleicht andere Anforderungen an ein Dateisystem. btrfs ist noch in Entwicklung. Es ist stabil, aber noch nicht fertig. Vielleicht passt das eine oder andere noch nicht so gut für Server... RedHat will sicher ein gutes Produkt für den Einsatzzweck der Kunden liefern, und btrfs könnte dafür noch nicht geeignet sein. Aber tot ist es deswegen sicher nicht. Dann wäre KDE nämlich auch tot, wenn es nach RedHat ginge^{Quelle (englisch)}...

Woher kommt überhaupt diese RedHat-fixierung?!? ‣Andreas•⚖ 23:31, 18. Dez. 2018 (CET)

Das kommt vielleicht daher, weil RedHat halt einen große Fangemeinde ("Marktanteil") hat? ;-) --Guenni60 (Diskussion) 16:04, 20. Apr. 2019 (CEST)

Deduplizierung kostenpflichtig bei Red Hat

Das stimmt nicht. Virtual Data Optimizer (VDO) mit Deduplizierung/Komprimierung ist seit RHEL 7.5 Bestandteil der Auslieferung und im Preis inklusive. Wer es kostenlos haben will, nimmt CentOS oder andere Abkömmlinge. --2001:A62:1584:1101:D5C7:9FB2:A919:81D2 11:37, 16. Dez. 2018 (CET)

Interessant. Deduplizierung ist ein im Dateisystem integrierter Bestandteil von btrfs. Andere Dateisysteme haben diese Funktion oder auch nicht. So wie Hardlinks z.B. auf FAT-Dateisystemen nicht möglich sind, kann auch kein Anbieter (RedHat) Deduplizierung anbieten auf Dateisystemen, die das nicht können. Oder Sparse-Dateien. Oder Dateien > 4GB. Oder Attribute wie Erstellungs-/Änderungs-/Zugriffszeit. Oder Besitzverhältnisse (Owner).

Und wenn es ein Dateisystem kann, dann braucht man nur ein Tool dafür. cp reicht, denn mit cp --reflink kann man einen Klon (Copy-on-Write) anlegen.

Übrigens: Dateisysteme, die Deduplizieren können, sind u.a. auch XFS und ZFS. XFS aber auch erst in einer späteren Version. Gerade btrfs und XFS waren in den letzten Jahren ordentlich weiterentwickelt worden, daher sollte man tunlichst auch einen aktuellen Kernel und die letzten Versionen von Dateisystem-Werkzeugen verwenden, wenn man diese Funktionen nutzen möchte. Wenn RedHat das bei RHEL nicht macht, dann haben die naturgemäß Einschränkungen.

‣Andreas•⚖ 12:01, 16. Dez. 2018 (CET)

Vermisst im Artikel & Artikelverbesserung

Hallo WP-Gemeinde,

ich vermisse in diesem Artikel ob Btrfs eines kann: Die Fähigkeit gelöschte Dateien und/oder Verzeichnisse wiederherzustellen. Das wird mit keinem Wort erwähnt.

Und wenn Btrfs bis heute noch nicht das Standard-Betriebssystem bei LINUX geworden ist, dann hängt das vielleicht auch mit der schlechten Darstellung in diesem WP-Artikel zusammen? (Noch ein Wort vorweg: Ich benutze bis heute immer noch ext3 auf meinen Servern.)

Jedenfalls möchte ich hier einmal kurz alle Eigenschaften ("Features") von btrfs auflisten, soweit ich sie beim Studium des Artikels und der Diskussionsseite verstanden habe: (Noch ein Hinweis: Sollten Fehler oder Irrtümer darin sein, dann bitte verbessern/korrigieren/ergänzen, ggfs. mit Durchstreichen: abcxyz )

• Gesamtgröße eines Partition/Datenträgers(?): 16 EiB
• Größe einer Datei: 16 EiB (ergo ermöglicht Dateien > 4 GiB)
• Größe eines Blockes:  ???
• Mögliche Anzahl aller Dateien: 2⁶⁴ ~ 18,4 * 10¹⁸ Bytes (10¹⁸ == 1 Trillion (Zehnerpotenz))

• Länge eines Dateinamens : Maximal 255 Zeichen/Byte
• Verfügbare Attribute:
• - Owner
• - Erstellungszeit
• - Änderungszeit
• - (Letzte) Zugriffszeit
• Wiederherstellung gelöschter Dateien/Verzeichnisse: Möglich?
• Dateisystem vergrößern/verkleiner während laufenden Betriebes: Durchführbar
• Transparente Komprimierung: Ja
• Deduplizierung möglich: Ja (Deduplikation)
• Copy-On-Write: Ja
• Sparse-Dateien möglich: Ja (Was ist das?)
• Verfügt über RAID0, RAID1, RAID5, RAID6, RAID10, Trible-RAID
• Journaling vorhanden ?: Unbekannt (Ist für SSD eher unpraktisch bzw. wenig sinnvoll)
• Volumen-Management: Vorhanden
• Prüfsummenbasierter Schutz: Ja

Ergo/Schlußfolgerung: Btrfs ist in vielen oder fast allen Distributionen vorhanden (Ausnahme: RedHat). Es gibt auch eine Version für Windows bzw. ReactOs siehe WinBtrfs. Es ist stabil, aber in einigen Teilen noch entwicklungsbedürftig (Müsste hier im Artikel auch begründet und/oder besser erläutert werden).

Soweit mein Erkenntnisstand aus diesem Artikel und der Diskussion hier.

Ich denke auch, daß der Abschnitt "Eigenschaften" entschlackt werden müsste. Er geht zu sehr in spezifische Details, und die Bezugnahme auf das ZFS ist für den Leser, der sich über Btrfs informieren möchte, wenig hilfreich, weil er sich dann dort auch erst wieder hinein lesen muss (müsste?!?). Ergo: Die Bezugnahme und Vergleiche zu ZFS gehörten weiter unten in einen separaten Abschnitt besser platziert.

Am Ende des Abschnittes "Eigenschaften" ist ja schon einiges aufgeführt, was der Übersichtlichkeit dient und die Vorzügen von Btrfs sind. Und natürlich dürfen auch Kritik bzw. die Schwachpunkte aufgeführt und erwähnt werden. Die obige Liste darf gerne in den Artikel übernommen werden, wollte diesen aber auch nicht gleich entstellen, da ich kein fundierter Kenner dieses Dateisystems bin.

Soweit mein Eindruck und Kenntnisstand, Gruß --Guenni60 (Diskussion) 17:14, 20. Apr. 2019 (CEST)

RAID 1 einer ungeraden Anzahl von Datenträgern unterschiedlicher Kapazität

Im Text heißt es: "So wird es möglich einen RAID 1 aus einer ungeraden Anzahl von Datenträgern unterschiedlicher Kapazität, unter voller Ausnutzung derer Kapazität, zu bilden."

Abgesehen davon, dass es wohl "ihrer Kapazität" heißen sollte, verstehe ich das nicht. Zumindest müsste es weitere Randbedingungen geben, denn wenn ich einer Terabyte-Platte zwei Floppys zurseite stelle, hätte ich drei Datenträger unterschiedlicher Kapazität, von denen ich aber offensichtlich nicht die volle Kapazität von 1000002,9 kB entsprechend ("jeder Datenbereich auf wenigstens zwei Datenträgern") nutzen kann.

-- Pemu (Diskussion) 03:13, 8. Aug. 2019 (CEST)

Ich verstehe es auch nicht.

How much space do I get with unequal devices in RAID-1 mode? Anscheinend funktioniert es aber...

‣Andreas•⚖ 12:48, 18. Nov. 2019 (CET)

Dort steht "The general rule of thumb is if your largest device is bigger than all of the others put together, then you will get as much space as all the smaller devices added together. Otherwise, you get half of the space of all of your devices added together." (Hervorhebung von mir.)

Vor allem steht das im Widerspruch zur stellt das eine starke Einschränkung der o.g. Aussage in unserem Artikel dar.

-- Pemu (Diskussion) 00:27, 21. Aug. 2020 (CEST); Pemu (Diskussion) 00:35, 21. Aug. 2020 (CEST)

Zwei ext3 in ein Btrfs konvertiert?

Im Text stand vor meinem heutigen Edit (sinngemäß)

Zu Btrfs gehört das Dienstprogramm btrfs-convert, mit dem bestehende ext3- und ext4-Dateisysteme in ein Btrfs-Dateisystem konvertiert werden können.

Ich habe es eklatant inhaltlich geändert, weil ich vermute, dass es so gemeint war, wie es jetzt da steht, also

Zu Btrfs gehört das Dienstprogramm btrfs-convert, mit dem bestehende ext3- und ext4-Dateisysteme in Btrfs-Dateisysteme konvertiert werden können.

Falls es doch so gemeint war (also zwei ext3 in ein Btrfs konvertiert werden können), so sollte es genauer erläutert werden.

-- Pemu (Diskussion) 00:20, 21. Aug. 2020 (CEST)

Veralteter Text

Der Text ist an vielen Stellen veraltet und müsste mal ein Update erfahren. Beispiel Redhat/Fedora: https://fedoramagazine.org/working-with-btrfs-general-concepts/ "This article is part of a series of articles that takes a closer look at Btrfs. This is the default filesystem for Fedora Workstation and Fedora Silverblue since Fedora Linux 33." --2A02:810D:A040:1AB:FC3F:8E95:C049:1DE6 09:37, 12. Okt. 2022 (CEST)

Quelle Fehlt/Theoriefindung

Im Text steht: Ein Grund könnte auch sein, dass Red Hat Konkurrenz im eigenen Haus vermeiden möchte, welcher durch den Zukauf von Permabit entstanden wäre. Um an Features wie Daten-Deduplizierung zu gelangen, müssen Kunden von Red Hat so zu einer kommerziellen, kostenpflichtigen Erweiterung greifen.

Die angefügte Quelle belegt zwar, dass RH Permabit gekauft hat; aber nirgendwo wird erwähnt, dass das irgendeinen Einfluss auf die Verwendung bzw. nicht-Verwendung von Btrfs hatte. Das klingt für mich offen gestanden ziemlich nach Theoriefindung... Wenn hier kein Widerspruch kommt, würde ich deshalb demnächst rausnehmen. --KizzyCode (Diskussion) 04:03, 5. Mär. 2023 (CET)

Der Text und die Quelle wurden 2018 hier eingefügt. Ich kann jetzt auch nicht entdecken, dass die These im Text irgendwie durch die Quelle gestützt würde. --AchimP (Diskussion) 14:30, 5. Mär. 2023 (CET)

Ich hab das jetzt mal geändert, aber man kann es noch verbessern. ‣Andreas•⚖ 11:24, 6. Mär. 2023 (CET)

Cool, das ist doch schon mal viel besser – danke! --KizzyCode (Diskussion) 21:38, 6. Mär. 2023 (CET)