Diskussion:Btrfs

message: 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)
thread_title:  Fedora 17 wird doch btrfs nicht als standard Dateisystem verwenden 

message: 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)
replies: text: 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)

text: 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)
thread_title:  dateiname 

message: 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)
replies: text: 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)
thread_title:  Löschwut 

message: 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)
replies: text: 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)
replies: text: 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)
replies: text:  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)

text: 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)

text: 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)
thread_title:  Benutzbarkeit 

message: 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)
replies: text: 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)
replies: text: 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)
thread_title:  Wie ermöglicht es so große Dateien? 

message: 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)
thread_title:  Abschnitt Geschichte... 

message: 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)
replies: text: Archlinux, Gentoo, openSUSE um nur mal 3 zu nennen Vamp898 (Diskussion) 09:22, 24. Jul. 2012 (CEST)
thread_title:  Distributionen 

message: 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)
replies: text: 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)
thread_title:  Stand aktualisiert 

message: 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)
replies: text: 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)
thread_title:  Btrfs weist zahlreiche Gemeinsamkeiten mit ZFS auf. ??? 

message: 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)
replies: text: 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)
thread_title:  Btrfs wird ext4 ersetzen? 

message: 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)
thread_title:  Läuft wohl auch auf ''Synologys NAS-Systemen'' 

message: 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)
replies: text: 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)
thread_title:  journaling 

message: 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:  264  ~  18,4 * 1018 Bytes  (1018 == 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)
thread_title:  Vermisst im Artikel & Artikelverbesserung 

message: 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)
thread_title:  Zwei ext3 in ein Btrfs konvertiert? 

message: 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)
thread_title:  Veralteter Text 

message: 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)
replies: text: 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)
replies: text: Ich hab das jetzt mal geändert, aber man kann es noch verbessern. ‣Andreas•⚖ 11:24, 6. Mär. 2023 (CET)
replies: text: Cool, das ist doch schon mal viel besser – danke! --KizzyCode (Diskussion) 21:38, 6. Mär. 2023 (CET)
thread_title:  Quelle Fehlt/Theoriefindung