Btrfs – Wikipedia

Posted on by
before-content-x4

B-Tree-Dateisystem

Nicht zu verwechseln mit dem BitTorrent-Dateisystem BTFS.
Btrfs
Entwickler Facebook, Fujitsu, Fusion-IO, Intel, Linux Foundation, Netgear, Oracle Corporation, Red Hat, STRATO AG und openSUSE[1]
Vollständiger Name B-Tree-Dateisystem
Eingeführt Linux-Kernel 2.6.29, März 2009;; Vor 11 Jahren ((2009-03)
Strukturen
Verzeichnisinhalt B-Baum
Dateizuordnung Ausmaße
Grenzen
Max. Volumengröße 16 EiB[2][a]
Max. Dateigröße 16 EiB[2][a]
Max. Anzahl der Dateien 264[b][3]
Max. Dateinamenlänge 255 ASCII-Zeichen (weniger für Multibyte-Zeichencodierungen wie Unicode)
Zulässige Zeichen in Dateinamen Alle außer '/' und NUL (('')
Eigenschaften
Termine aufgezeichnet Schöpfung (otime),[4] Änderung (mtime), Attributänderung (ctime) und Zugriff (atime)
Datumsbereich 64-Bit-Int-Offset mit Vorzeichen von 1970-01-01T00: 00: 00Z[5]
Datumsauflösung Nanosekunde
Attribute POSIX und erweiterte Attribute
Dateisystemberechtigungen POSIX und ACL
Transparente Komprimierung Ja (zlib, LZO[6] und (seit 4.14) ZSTD[7])
Transparente Verschlüsselung Geplant[8]
Datendeduplizierung Ja[9]
Copy-on-Write Ja
Andere
Unterstützte Betriebssysteme Linux, ReactOS[10]
Webseite btrfs.wiki.kernel.org Bearbeiten Sie dies bei Wikidata
after-content-x4

Btrfs (ausgesprochen als “Butteraufheben”,[11] “besserer FS”,[8] “Butter FS”,[12] “b-Baum FS”,[12] oder einfach durch Buchstabieren) ist ein Computerspeicherformat, das ein Dateisystem basierend auf dem COW-Prinzip (Copy-on-Write) mit einem gemeinsam entwickelten logischen Volume-Manager (nicht zu verwechseln mit dem LVM von Linux) kombiniert. Es wurde ursprünglich 2007 von der Oracle Corporation für die Verwendung unter Linux entwickelt. Seit November 2013 wurde das On-Disk-Format des Dateisystems im Linux-Kernel für stabil erklärt.[13] Laut Oracle ist Btrfs “kein echtes Akronym”.[14]

Btrfs soll das Fehlen von Pooling, Snapshots, Prüfsummen und integriertem Multi-Device-Spanning in Linux-Dateisystemen beheben.[8] Chris Mason, der Hauptautor von Btrfs, erklärte, sein Ziel sei es, “zu vermieten” [Linux] Skala für den Speicher, der verfügbar sein wird. Bei der Skalierung geht es nicht nur darum, den Speicher zu adressieren, sondern auch darum, ihn über eine saubere Oberfläche verwalten und verwalten zu können, damit die Benutzer sehen können, was verwendet wird, und ihn zuverlässiger machen können. “[15]

Geschichte[edit]

Die Kerndatenstruktur von Btrfs – der Copy-on-Write-B-Baum – wurde ursprünglich vom IBM-Forscher Ohad Rodeh bei einer Präsentation auf der USENIX 2007 vorgeschlagen.[16] Chris Mason, ein Ingenieur, der zu dieser Zeit an ReiserFS für SUSE arbeitete, kam später in diesem Jahr zu Oracle und begann mit der Arbeit an einem neuen Dateisystem, das auf diesen B-Bäumen basiert.[17]

Im Jahr 2008 erklärte Theodore Ts’o, der Hauptentwickler der Dateisysteme ext3 und ext4, dass ext4 zwar verbesserte Funktionen aufweist, dies jedoch keinen großen Fortschritt darstellt. Es nutzt alte Technologie und ist eine Lücke. Ts’o sagte, dass Btrfs die bessere Richtung ist, weil “es Verbesserungen in Bezug auf Skalierbarkeit, Zuverlässigkeit und einfache Verwaltung bietet”.[18] Btrfs hat auch “eine Reihe der gleichen Designideen wie reiser3 / 4”.[19]

Btrfs 1.0 mit dem endgültigen Format auf der Festplatte war ursprünglich für eine Veröffentlichung Ende 2008 geplant.[20] und wurde schließlich 2009 in die Linux-Kernel-Hauptlinie aufgenommen.[21] Mehrere Linux-Distributionen bieten Btrfs während der Installation als experimentelle Auswahl des Root-Dateisystems an.[22][23][24]

Im Juli 2011 wurden die automatischen Defragmentierungs- und Bereinigungsfunktionen von Btrfs in Version 3.0 der Linux-Kernel-Hauptlinie zusammengeführt.[25] Neben Mason bei Oracle trug Miao Xie bei Fujitsu zur Leistungsverbesserung bei.[26] Im Juni 2012 verließ Chris Mason Oracle für Fusion-io, das er ein Jahr später mit Josef Bacik verließ, um sich Facebook anzuschließen. Während seiner Zeit bei beiden Unternehmen setzte Mason seine Arbeit an Btrfs fort.[27][17]

 after-content-x4

Im Jahr 2012 haben zwei Linux-Distributionen Btrfs vom experimentellen zum produktiven oder unterstützten Status verschoben: Oracle Linux im März,[28] gefolgt von SUSE Linux Enterprise im August.[29]

Im Jahr 2015 wurde Btrfs als Standarddateisystem für SUSE Linux Enterprise Server 12 übernommen.[30]

Im August 2017 gab Red Hat in den Versionshinweisen für Red Hat Enterprise Linux (RHEL) 7.4 bekannt, dass es nicht mehr geplant ist, Btrfs, das seit RHEL 6 Beta als “Technologievorschau” enthalten war, auf eine vollständig unterstützte Funktion zu verschieben. unter Hinweis darauf, dass es in der RHEL 7-Release-Serie verfügbar bleiben würde.[31] Btrfs wurde im Mai 2019 aus RHEL 8 entfernt.[32]

Im Jahr 2020 wurde Btrfs als Standarddateisystem für Fedora 33 ausgewählt.[33]

Eigenschaften[edit]

Implementiert[edit]

Ab Version 5.0 des Linux-Kernels implementiert Btrfs die folgenden Funktionen:[34][35]

Implementiert, aber nicht für die Produktion empfohlen[edit]

Geplant, aber noch nicht umgesetzt[edit]

2009 sollte Btrfs einen mit ZFS vergleichbaren Funktionsumfang anbieten, der von Sun Microsystems entwickelt wurde.[53] Nach der Übernahme von Sun durch Oracle im Jahr 2009 beschlossen Mason und Oracle, die Entwicklung von Btrfs fortzusetzen.[54]

Klonen[edit]

Btrfs bietet eine Klon Vorgang, der atomar einen Copy-on-Write-Snapshot einer Datei erstellt. Solche geklonten Dateien werden manchmal als bezeichnet reflinksim Lichte des vorgeschlagenen zugehörigen Linux-Kernel-Systemaufrufs.[55]

Durch das Klonen erstellt das Dateisystem keinen neuen Link, der auf einen vorhandenen Inode verweist. Stattdessen wird ein neuer Inode erstellt, der zunächst dieselben Festplattenblöcke wie die Originaldatei verwendet. Infolgedessen funktioniert das Klonen nur innerhalb der Grenzen desselben Btrfs-Dateisystems. Seit Version 3.6 des Linux-Kernels kann es jedoch unter bestimmten Umständen die Grenzen von Subvolumes überschreiten.[56][57] Die tatsächlichen Datenblöcke werden nicht dupliziert. Gleichzeitig sind aufgrund der Copy-on-Write-Eigenschaft (CoW) von Btrfs Änderungen an den geklonten Dateien in der Originaldatei nicht sichtbar und umgekehrt.[58]

Das Klonen sollte nicht mit festen Links verwechselt werden. Hierbei handelt es sich um Verzeichniseinträge, die mehrere Dateinamen mit tatsächlichen Dateien in einem Dateisystem verknüpfen. Während Hardlinks als unterschiedliche Namen für dieselbe Datei verwendet werden können, bietet das Klonen in Btrfs unabhängige Dateien, die anfänglich alle ihre Festplattenblöcke gemeinsam nutzen.[58][59]

Die Unterstützung für diese Btrfs-Funktion wurde in Version 7.5 der GNU-Coreutils über die hinzugefügt --reflink Option zum cp Befehl.[60][61]

Neben dem Klonen von Daten (FICLONE) Unterstützt Btrfs auch die Out-of-Band-Deduplizierung über FIDEDUPERANGE. Mit dieser Funktion können zwei Dateien mit (sogar teilweise) identischen Daten gemeinsam genutzt werden.[62][9]

Subvolumes und Schnappschüsse[edit]

Ein Btrfs-Subvolume kann als separater POSIX-Dateinamensraum betrachtet werden, der durch Übergabe separat gemountet werden kann subvol oder subvolid Optionen zum mount(8) Nützlichkeit. Der Zugriff kann auch durch Mounten des Subvolumes der obersten Ebene erfolgen. In diesem Fall sind Subvolumes als Unterverzeichnisse sichtbar und zugänglich.[63]

Subvolumes können an jeder Stelle innerhalb der Dateisystemhierarchie erstellt und auch verschachtelt werden. Verschachtelte Subvolumes werden als Unterverzeichnisse in ihren übergeordneten Subvolumes angezeigt, ähnlich wie ein Subvolume der obersten Ebene seine Subvolumes als Unterverzeichnisse darstellt. Das Löschen eines Subvolumes ist erst möglich, wenn alle darunter liegenden Subvolumes in der Verschachtelungshierarchie gelöscht wurden. Daher können Subvolumes der obersten Ebene nicht gelöscht werden.[64]

Jedes Btrfs-Dateisystem verfügt immer über ein Standard-Subvolume, das anfänglich als Subvolume der obersten Ebene festgelegt ist und standardmäßig bereitgestellt wird, wenn keine Auswahloption für das Subvolume übergeben wird mount. Das Standard-Subvolumen kann nach Bedarf geändert werden.[64]

Ein Btrfs-Snapshot ist ein Subvolume, das seine Daten (und Metadaten) mithilfe der Copy-on-Write-Funktionen von Btrfs mit einem anderen Subvolume teilt. Änderungen an einem Snapshot sind im ursprünglichen Subvolume nicht sichtbar. Sobald ein beschreibbarer Schnappschuss erstellt wurde, kann er als alternative Version des ursprünglichen Dateisystems behandelt werden. Um beispielsweise einen Rollback zu einem Snapshot durchzuführen, muss ein modifiziertes Original-Subvolume abgemeldet und der Snapshot an seiner Stelle bereitgestellt werden. Zu diesem Zeitpunkt kann auch das ursprüngliche Subvolumen gelöscht werden.[63]

Aufgrund der CoW-Funktion (Copy-on-Write) von Btrfs werden Snapshots schnell erstellt, während anfangs nur sehr wenig Speicherplatz benötigt wird. Da ein Snapshot ein Subvolume ist, ist es auch möglich, verschachtelte Snapshots zu erstellen. Das Aufnehmen von Schnappschüssen eines Subvolumens ist kein rekursiver Prozess. Wenn also ein Snapshot eines Subvolumes erstellt wird, wird jedes Subvolume oder jeder Snapshot, den das Subvolume bereits enthält, einem leeren Verzeichnis mit demselben Namen im Snapshot zugeordnet.[63][64]

Das Erstellen von Snapshots eines Verzeichnisses ist nicht möglich, da nur Subvolumes Snapshots enthalten können. Es gibt jedoch eine Problemumgehung, die Reflinks umfasst, die über Subvolumes verteilt sind: Es wird ein neues Subvolume erstellt, das subfluidübergreifende Reflinks zum Inhalt des Zielverzeichnisses enthält. Wenn dies verfügbar ist, kann ein Snapshot dieses neuen Volumes erstellt werden.[56]

Ein Subvolume in Btrfs unterscheidet sich erheblich von einem herkömmlichen logischen LVM-Volume (Logical Volume Manager). Bei LVM ist ein logisches Volume ein separates Blockgerät, ein Btrfs-Subvolume jedoch nicht, und es kann nicht auf diese Weise behandelt oder verwendet werden.[63] Das Erstellen von dd- oder LVM-Snapshots von btrfs führt zu Datenverlust, wenn entweder das Original oder die Kopie bereitgestellt wird, während sich beide auf demselben Computer befinden.[65]

Senden empfangen[edit]

Bei einem beliebigen Paar von Subvolumes (oder Snapshots) kann Btrfs einen binären Unterschied zwischen ihnen erzeugen (mithilfe von btrfs send Befehl), der später wiedergegeben werden kann (mit btrfs receive), möglicherweise auf einem anderen Btrfs-Dateisystem. Die Sende-Empfangs-Funktion erstellt (und wendet) effektiv eine Reihe von Datenänderungen an, die zum Konvertieren eines Teilvolumens in ein anderes erforderlich sind.[46][66]

Die Sende- / Empfangsfunktion kann mit regelmäßig geplanten Snapshots zum Implementieren einer einfachen Form der Dateisystemreplikation oder zum Durchführen inkrementeller Sicherungen verwendet werden.[46][66]

Kontingentgruppen[edit]

EIN Quotengruppe (oder qgroup) legt eine Obergrenze für den Speicherplatz fest, den ein Subvolume oder Snapshot belegen kann. Ein neuer Snapshot verbraucht zunächst kein Kontingent, da seine Daten für das übergeordnete Element freigegeben werden. Danach fallen jedoch Gebühren für neue Dateien und Kopiervorgänge für vorhandene Dateien an. Wenn Kontingente aktiv sind, wird mit jedem neuen Teilvolumen oder Snapshot automatisch eine Kontingentgruppe erstellt. Diese anfänglichen Kontingentgruppen sind Bausteine, die gruppiert werden können (mit dem btrfs qgroup Befehl) in Hierarchien, um Kontingentpools zu implementieren.[48]

Kontingentgruppen gelten nur für Subvolumes und Snapshots, während die Durchsetzung von Kontingenten für einzelne Unterverzeichnisse, Benutzer oder Benutzergruppen nicht möglich ist. Problemumgehungen sind jedoch möglich, indem für alle Benutzer oder Benutzergruppen, für deren Durchsetzung ein Kontingent erforderlich ist, unterschiedliche Subvolumes verwendet werden.

In-Place-Konvertierung von ext2 / 3/4 und ReiserFS[edit]

Da nur sehr wenige Metadaten an festen Orten verankert sind, kann Btrfs sich verziehen, um ungewöhnlichen räumlichen Layouts der Backend-Speichergeräte zu entsprechen. Das btrfs-convert Das Tool nutzt diese Möglichkeit, um eine direkte Konvertierung eines ext2 / 3/4 oder ReiserFS-Dateisystems durchzuführen, indem die entsprechenden Btrfs-Metadaten in seinem nicht zugewiesenen Speicherplatz verschachtelt werden, während eine unveränderte Kopie des ursprünglichen Dateisystems erhalten bleibt.[67]

Bei der Konvertierung wird eine Kopie der gesamten ext2 / 3/4 Metadaten erstellt, während die Btrfs-Dateien einfach auf dieselben Blöcke verweisen, die von den ext2 / 3/4 Dateien verwendet werden. Dadurch wird der Großteil der Blöcke zwischen den beiden Dateisystemen gemeinsam genutzt, bevor die Konvertierung dauerhaft wird. Dank des Copy-on-Write-Charakters von Btrfs bleiben die Originalversionen der Dateidatenblöcke bei allen Dateimodifikationen erhalten. Bis die Konvertierung dauerhaft wird, werden nur die Blöcke, die in ext2 / 3/4 als frei markiert wurden, verwendet, um neue Btrfs-Änderungen zu speichern. Dies bedeutet, dass die Konvertierung jederzeit rückgängig gemacht werden kann (obwohl dadurch alle nach der Konvertierung vorgenommenen Änderungen gelöscht werden zu Btrfs).[67]

Alle konvertierten Dateien sind im Standard-Subvolume des Btrfs verfügbar und beschreibbar. Eine Datei mit geringer Dichte, die alle Verweise auf das ursprüngliche ext2 / 3/4-Dateisystem enthält, wird in einem separaten Subvolume erstellt, das als schreibgeschütztes Disk-Image eigenständig bereitgestellt werden kann, sodass auf das ursprüngliche und das konvertierte Dateisystem zugegriffen werden kann gleiche Zeit. Durch das Löschen dieser Datei mit geringer Dichte wird Speicherplatz frei und die Konvertierung wird dauerhaft.[67]

Ab Juni 2015 und 4.x-Versionen der Linux-Kernel-Hauptlinie wurde die direkte ext3 / 4-Konvertierung als ungetestet angesehen und nur selten verwendet.[67] Das Feature wurde jedoch 2016 für von Grund auf neu geschrieben btrfs-progs 4.6.[44] und gilt seitdem als stabil.

Die direkte Konvertierung von ReiserFS wurde im September 2017 mit Kernel 4.13 eingeführt.[68]

Union Montage- / Saatgutvorrichtungen[edit]

Beim Erstellen eines neuen Btrfs kann ein vorhandenes Btrfs als schreibgeschütztes “Seed” -Dateisystem verwendet werden.[69] Das neue Dateisystem fungiert dann als Copy-on-Write-Overlay auf dem Seed, als eine Form der Union-Montage. Der Startwert kann später vom Btrfs getrennt werden. Zu diesem Zeitpunkt kopiert der Neuausgleich einfach alle Startdaten, auf die das neue Dateisystem noch verweist, bevor er getrennt wird. Mason hat vorgeschlagen, dass dies für ein Live-CD-Installationsprogramm nützlich sein kann, das möglicherweise von einem schreibgeschützten Btrfs-Seed auf einer optischen Disc bootet, sich im Hintergrund neu auf die Zielpartition auf der Installationsdiskette verteilt, während der Benutzer weiter arbeitet, und dann auswirft die CD, um die Installation ohne Neustart abzuschließen.[70]

Verschlüsselung[edit]

In seinem Interview von 2009 erklärte Chris Mason, dass die Unterstützung der Verschlüsselung für Btrfs geplant sei.[71] In der Zwischenzeit besteht eine Problemumgehung für die Kombination der Verschlüsselung mit Btrfs darin, einen Verschlüsselungsmechanismus für die gesamte Festplatte wie dm-crypt / LUKS auf den zugrunde liegenden Geräten zu verwenden und das Btrfs-Dateisystem auf dieser Ebene zu erstellen.

Ab 2020 Die Entwickler arbeiteten daran, verschlüsselten Hash wie HMAC (SHA256) hinzuzufügen.[72]

Überprüfung und Wiederherstellung[edit]

Unix-Systeme verlassen sich traditionell auf “fsck” -Programme, um Dateisysteme zu überprüfen und zu reparieren. Diese Funktionalität wird über die implementiert btrfs check Programm. Seit Version 4.0 gilt diese Funktionalität als relativ stabil. Ab August 2017 wird in der btrfs-Dokumentation jedoch empfohlen, diese erst zu verwenden, nachdem andere Wiederherstellungsmethoden ausprobiert wurden.[73]

Es gibt ein anderes Tool namens btrfs-restoreDies kann verwendet werden, um Dateien aus einem nicht bereitstellbaren Dateisystem wiederherzustellen, ohne das fehlerhafte Dateisystem selbst zu ändern (dh zerstörungsfrei).[74]

Bei normaler Verwendung ist Btrfs größtenteils selbstheilend und kann sich zum Zeitpunkt der Bereitstellung von abgebrochenen Wurzelbäumen erholen, da regelmäßig alle 30 Sekunden Daten in den permanenten Speicher gelöscht werden. Isolierte Fehler führen daher dazu, dass beim nächsten Mount maximal 30 Sekunden lang Änderungen am Dateisystem verloren gehen.[75] Dieser Zeitraum kann durch Angabe eines gewünschten Werts (in Sekunden) für das geändert werden commit Mount-Option.[76][77]

Ohad Rodehs ursprünglicher Vorschlag auf der USENIX 2007 stellte fest, dass B + -Bäume, die häufig als Datenstrukturen auf der Festplatte für Datenbanken verwendet werden, Snapshots auf der Basis von Copy-on-Write nicht effizient zulassen konnten, da ihre Blattknoten miteinander verknüpft waren: Wenn ein Blatt kopiert wurde -auf schriftlich müssten seine Geschwister und Eltern genauso sein wie ihr Geschwister und Eltern und so weiter, bis der gesamte Baum kopiert wurde. Er schlug stattdessen einen modifizierten B-Baum vor (der keine Blattverknüpfung aufweist), mit einem Refcount, der jedem Baumknoten zugeordnet ist, aber in einer ad-hoc-freien Kartenstruktur gespeichert ist, und bestimmten Relaxationen der Ausgleichsalgorithmen des Baums, damit sie beim Schreiben kopiert werden freundlich. Das Ergebnis wäre eine Datenstruktur, die für einen Hochleistungsobjektspeicher geeignet ist, der Snapshots zum Kopieren beim Schreiben ausführen und gleichzeitig eine gute Parallelität gewährleisten kann.[16]

Später in diesem Jahr begann Chris Mason bei Oracle mit der Arbeit an einem Snapshot-fähigen Dateisystem, das diese Datenstruktur fast ausschließlich verwendet – nicht nur für Metadaten und Dateidaten, sondern auch rekursiv, um die Speicherplatzzuweisung der Bäume selbst zu verfolgen. Auf diese Weise konnten alle Durchläufe und Änderungen über einen einzigen Codepfad geleitet werden, für den Funktionen wie Copy-on-Write, Prüfsumme und Spiegelung nur einmal implementiert werden mussten, um das gesamte Dateisystem zu unterstützen.[53]

Btrfs besteht aus mehreren Ebenen solcher Bäume, die alle dieselbe B-Tree-Implementierung verwenden. Die Bäume speichern Generika Artikel sortiert nach einem 136-Bit-Schlüssel. Die höchstwertigen 64 Bit des Schlüssels sind eindeutig Objekt Identifikation. Die mittleren acht Bits sind ein Elementtypfeld: Ihre Verwendung ist fest in Code als Elementfilter in Baumsuchen verankert. Objekte kann mehrere Elemente verschiedener Typen haben. Die verbleibenden (niedrigstwertigen) 64 Bit werden typspezifisch verwendet. Daher werden Elemente für dasselbe Objekt im Baum nebeneinander angeordnet, gruppiert nach Typ. Durch Auswahl bestimmter Schlüsselwerte können Objekte außerdem Elemente desselben Typs in eine bestimmte Reihenfolge bringen.[53][3]

Innenbaumknoten sind einfach flache Listen von Schlüssel-Zeiger-Paaren, wobei der Zeiger die logische Blocknummer eines untergeordneten Knotens ist. Blattknoten enthalten Artikelschlüssel, die in die Vorderseite des Knotens gepackt sind, und Artikeldaten, die in das Ende gepackt sind, wobei die beiden beim Auffüllen des Blattes aufeinander zu wachsen.[53]

Dateisystembaum[edit]

In jedem Verzeichnis werden Verzeichniseinträge als angezeigt Verzeichniselemente, deren niedrigstwertige Bits von Schlüsselwerten ein CRC32C-Hash ihres Dateinamens sind. Ihre Daten sind a Standortschlüsseloder der Schlüssel des Inode-Elements, auf das es zeigt. Verzeichniselemente zusammen können somit als Index für Pfad-zu-Inode-Suchvorgänge fungieren, werden jedoch nicht für die Iteration verwendet, da sie nach ihrem Hash sortiert sind und diese effektiv zufällig permutieren. Dies bedeutet, dass Benutzeranwendungen, die Dateien in einem großen Verzeichnis durchlaufen und öffnen, viel mehr Festplattensuchen zwischen nicht benachbarten Dateien generieren würden – ein bemerkenswerter Leistungsverlust in anderen Dateisystemen mit Verzeichnissen mit Hash-Reihenfolge wie ReiserFS,[78] ext3 (mit aktivierten Htree-Indizes[79]) und ext4, die alle TEA-Hash-Dateinamen haben. Um dies zu vermeiden, hat jeder Verzeichniseintrag eine Verzeichnisindexelement, dessen Schlüsselwert des Elements auf einen Verzeichniszähler festgelegt ist, der mit jedem neuen Verzeichniseintrag erhöht wird. Die Iteration über diese Indexelemente gibt somit Einträge in ungefähr derselben Reihenfolge zurück, in der sie auf der Festplatte gespeichert sind.

Dateien mit festen Links in mehreren Verzeichnissen haben mehrere Referenzelemente, eines für jedes übergeordnete Verzeichnis. Dateien mit mehreren Hardlinks in der gleich Verzeichnis Packen Sie alle Dateinamen der Links in dasselbe Referenzelement. Dies war ein Konstruktionsfehler, der die Anzahl der Hardlinks im selben Verzeichnis auf so viele beschränkte, wie viele in einen einzelnen Baumblock passen konnten. (Bei einer Standardblockgröße von 4 KB, einer durchschnittlichen Dateinamenlänge von 8 Byte und einem Header pro Dateiname von 4 Byte wären dies weniger als 350.) Anwendungen, bei denen mehrere Hardlinks mit demselben Verzeichnis stark genutzt wurden, z Es wurde beobachtet, dass Git, GNUS, GMame und BackupPC bei dieser Grenze versagen.[80] Das Limit wurde schließlich entfernt[81] (und ab Oktober 2012 wurde zusammengelegt[82] bevorstehende Veröffentlichung in Linux 3.7) durch Einführung von Spillover erweiterte Referenzelemente um Hardlink-Dateinamen zu speichern, die sonst nicht passen.

Ausmaße[edit]

Dateidaten werden außerhalb des Baums in gespeichert AusmaßeDies sind zusammenhängende Läufe von Datenträgerdatenblöcken. Umfangsblöcke sind standardmäßig 4 KB groß, haben keine Header und enthalten nur (möglicherweise komprimierte) Dateidaten. In komprimierten Bereichen werden einzelne Blöcke nicht separat komprimiert. Vielmehr erstreckt sich der Komprimierungsstrom über die gesamte Ausdehnung.

Dateien haben Umfang Datenelemente um die Ausmaße zu verfolgen, die ihren Inhalt enthalten. Der Schlüsselwert des Elements ist der Startbyte-Offset der Ausdehnung. Dies ermöglicht eine effiziente Suche in großen Dateien mit vielen Ausdehnungen, da die korrekte Ausdehnung für einen bestimmten Dateiversatz mit nur einer Baumsuche berechnet werden kann.

Snapshots und geklonte Dateien teilen sich Extents. Wenn ein kleiner Teil eines großen solchen Umfangs überschrieben wird, kann das resultierende Copy-on-Write drei neue Bereiche erzeugen: einen kleinen mit den überschriebenen Daten und zwei große mit unveränderten Daten auf beiden Seiten des Überschreibens. Um zu vermeiden, dass unveränderte Daten neu geschrieben werden müssen, kann stattdessen das Copy-on-Write erstellt werden Buchstützenumfangoder Extents, die einfach Teile bestehender Extents sind. Umfangsdatenelemente ermöglichen dies, indem sie einen Versatz in den Umfang einbeziehen, den sie verfolgen: Elemente für Buchstützen sind solche mit einem Versatz ungleich Null.[3]

Umfang Zuordnungsbaum[edit]

Das Extent Allocation Tree fungiert als Zuordnungszuordnung für das Dateisystem. Im Gegensatz zu anderen Bäumen haben Elemente in diesem Baum keine Objekt-IDs. Sie repräsentieren Regionen des Raums: Ihre Schlüsselwerte enthalten die Startversätze und Längen der Regionen, die sie repräsentieren.

Das Dateisystem unterteilt den zugewiesenen Speicherplatz in Blockgruppen Hierbei handelt es sich um Zuordnungsbereiche mit variabler Größe, die abwechselnd Metadatenbereiche (Baumknoten) und Datenbereiche (Dateiinhalte) bevorzugen. Das Standardverhältnis von Daten zu Metadatenblockgruppen beträgt 1: 2. Sie sollen Konzepte des Orlov-Blockzuweisers verwenden, um verwandte Dateien zusammen zuzuordnen und der Fragmentierung zu widerstehen, indem zwischen den Gruppen freier Speicherplatz gelassen wird. (Ext3-Blockgruppen haben jedoch feste Speicherorte, die aus der Größe des Dateisystems berechnet werden, während die in Btrfs dynamisch sind und nach Bedarf erstellt werden.) Jede Blockgruppe ist mit a verknüpft Blockgruppenelement. Inode-Elemente in der Dateisystemstruktur enthalten einen Verweis auf ihre aktuelle Blockgruppe.[3]

Umfang Elemente einen Rückverweis auf den Baumknoten oder die Datei enthalten, die diesen Umfang einnehmen. Es kann mehrere Rückverweise geben, wenn der Umfang zwischen Snapshots geteilt wird. Wenn zu viele Rückverweise vorhanden sind, um in den Artikel zu passen, werden sie einzeln angezeigt Umfang Datenreferenzelemente. Baumknoten wiederum haben Rückverweise auf ihre enthaltenen Bäume. Auf diese Weise können Sie ermitteln, welche Bereiche oder Baumknoten sich in einem beliebigen Bereich des Raums befinden, indem Sie einen B-Tree-Bereichssuchvorgang für ein Paar von Offsets durchführen, die diesen Bereich in Klammern setzen, und dann den Rückverweisen folgen. Zum Verschieben von Daten ermöglicht dies eine effiziente Aufwärtsbewegung der verschobenen Blöcke, um schnell alle Abwärtsverweise auf diese Blöcke zu finden und zu korrigieren, ohne das gesamte Dateisystem scannen zu müssen. Auf diese Weise kann das Dateisystem seinen Speicher online effizient verkleinern, migrieren und defragmentieren.

Der Extent-Zuordnungsbaum ist wie bei allen anderen Bäumen im Dateisystem Copy-on-Write. Schreibvorgänge in das Dateisystem können daher eine Kaskade verursachen, bei der geänderte Baumknoten und Dateidaten dazu führen, dass neue Extents zugewiesen werden, wodurch sich der Extent-Baum selbst ändert. Um das Erstellen einer Rückkopplungsschleife zu vermeiden, können Extent-Baumknoten, die sich noch im Speicher befinden, aber noch nicht auf der Festplatte festgeschrieben sind, an Ort und Stelle aktualisiert werden, um neue, beim Schreiben kopierte Extents widerzuspiegeln.

Theoretisch macht der Extent-Zuordnungsbaum eine herkömmliche Freiraum-Bitmap unnötig, da der Extent-Zuordnungsbaum als B-Baum-Version eines BSP-Baums fungiert. In der Praxis wird jedoch ein speicherinterner rot-schwarzer Baum von Bitmaps in Seitengröße verwendet, um die Zuweisungen zu beschleunigen. Diese Bitmaps bleiben auf der Festplatte erhalten (ab Linux 2.6.37 über das space_cache Mount-Option[83]) als besondere Ausmaße, die von Prüfsummen und Copy-on-Write ausgenommen sind. Die Extent-Elemente, die diese Extents verfolgen, werden im Stammbaum gespeichert.

Prüfsummenbaum und Schrubben[edit]

CRC-32C-Prüfsummen werden sowohl für Daten als auch für Metadaten berechnet und als gespeichert Prüfsummenelemente in einem Prüfsummenbaum. Es ist Platz für 256 Bit Metadatenprüfsummen und bis zu einem vollständigen Knoten (ungefähr 4 KB oder mehr) für Datenprüfsummen. Btrfs enthält Bestimmungen für zusätzliche Prüfsummenalgorithmen, die in zukünftigen Versionen des Dateisystems hinzugefügt werden sollen.[34][84]

Es gibt ein Prüfsummenelement pro zusammenhängendem Lauf zugeordneter Blöcke, wobei Prüfsummen pro Block Ende-zu-Ende in die Elementdaten gepackt werden. Wenn mehr Prüfsummen vorhanden sind, als passen, werden sie in ein anderes Prüfsummenelement in einem neuen Blatt verschoben. Wenn das Dateisystem beim Lesen eines Blocks eine Nichtübereinstimmung der Prüfsumme feststellt, versucht es zunächst, eine gute Kopie dieses Blocks von einem anderen Gerät abzurufen (oder zu erstellen) – wenn interne Spiegelungs- oder RAID-Techniken verwendet werden.[85][86]

Btrfs kann eine Online-Überprüfung des gesamten Dateisystems initiieren, indem ein Dateisystem-Scrub-Job ausgelöst wird, der im Hintergrund ausgeführt wird. Der Scrub-Job überprüft das gesamte Dateisystem auf Integrität und versucht automatisch, alle auf dem Weg gefundenen fehlerhaften Blöcke zu melden und zu reparieren.[85][87]

Protokollbaum[edit]

Eine fsync-Anforderung schreibt geänderte Daten sofort in einen stabilen Speicher. fsync-schwere Workloads (wie eine Datenbank oder eine virtuelle Maschine, deren Betriebssystem ausgeführt wird fsyncs häufig) kann möglicherweise eine Menge redundanter Schreib-E / A erzeugen, indem das Dateisystem gezwungen wird, wiederholt geänderte Teile von Bäumen wiederholt zu kopieren und in den Speicher zu leeren. Um dies zu vermeiden, ein temporäres Per-Subvolume Protokollbaum wird erstellt, um durch fsync ausgelöste Copy-on-Writes zu protokollieren. Holzbäume sind in sich geschlossen, verfolgen ihre eigenen Ausmaße und behalten ihre eigenen Prüfsummenelemente. Ihre Elemente werden beim nächsten vollständigen Baum-Commit oder (falls es zu einem Systemabsturz kam) beim nächsten Remount wiedergegeben und gelöscht.

Chunk- und Gerätebäume[edit]

Blockgeräte sind unterteilt in physische Brocken von 256 MB oder mehr. Physische Blöcke über mehrere Geräte hinweg können gespiegelt oder zu einem einzigen zusammengefasst werden logischer Teil. Diese logischen Blöcke werden zu einem einzigen logischen Adressraum zusammengefasst, den der Rest des Dateisystems verwendet.

Das Stück Baum Verfolgt dies, indem jedes Gerät darin als gespeichert wird Geräteelement und logische Stücke als Chunk-Kartenelemente, die eine Vorwärtszuordnung von logischen zu physischen Adressen bereitstellen, indem ihre Offsets in den niedrigstwertigen 64 Bit ihres Schlüssels gespeichert werden. Es gibt verschiedene Arten von Chunk-Kartenelementen:

Single
1 logischer zu 1 physischen Block
dup
1 logischer Block zu 2 physischen Blöcken auf 1 Blockgerät
raid0
N logische Blöcke zu N ≥ 2 physischen Blöcken über N ≥ 2 Blockgeräte
raid1
1 logischer Block zu 2 physischen Blöcken über 2 von N≥2 Blockgeräten,[88] im Gegensatz zu herkömmlichem RAID 1 mit N physischen Blöcken
raid1c3
1 logischer Block zu 3 physischen Blöcken von N≥3 Blockgeräten
raid1c4
1 logischer Block zu 4 physischen Blöcken von N ≥ 4 Blockgeräten
raid5
N (für N ≥ 2) logische Blöcke zu N + 1 physischen Blöcken über N + 1 Blockgeräte, wobei 1 physischer Block als Parität verwendet wird
raid6
N (für N ≥ 2) logische Blöcke zu N + 2 physischen Blöcken über N + 2 Blockgeräte, wobei 2 physische Blöcke als Parität verwendet werden

N. ist die Anzahl der Blockgeräte, die noch freien Speicherplatz haben, wenn der Block zugewiesen wird. Wenn N für die ausgewählte Spiegelung / Zuordnung nicht groß genug ist, ist im Dateisystem praktisch kein Speicherplatz mehr vorhanden.

Umzugsbäume[edit]

Bei Defragmentierungs-, Schrumpfungs- und Neuausgleichsvorgängen müssen die Ausmaße verschoben werden. Durch einfaches Kopieren beim Schreiben des Verschiebungsumfangs wird jedoch die Freigabe zwischen Snapshots unterbrochen und Speicherplatz belegt. Um die Freigabe zu erhalten, wird ein Update-and-Swap-Algorithmus mit einem speziellen Algorithmus verwendet Umzugsbaum dient als Arbeitsbereich für betroffene Metadaten. Der Umfang der Verlagerung wird zunächst an den Bestimmungsort kopiert. Wenn Sie dann die Rückreferenzen im Dateisystembaum des betroffenen Subvolumes nach oben verfolgen, werden die Metadaten, die auf den alten Bereich verweisen, schrittweise aktualisiert, um auf den neuen zu verweisen. Alle neu aktualisierten Elemente werden im Umzugsbaum gespeichert. Sobald die Aktualisierung abgeschlossen ist, werden Elemente im Umzugsbaum mit ihren Gegenstücken im betroffenen Subvolume ausgetauscht und der Umzugsbaum wird verworfen.[89]

Superblock[edit]

Alle Bäume des Dateisystems – einschließlich des Blockbaums selbst – werden in Blöcken gespeichert, was beim Mounten des Dateisystems zu einem potenziellen Bootstrapping-Problem führt. Um in einen Mount zu booten, wird eine Liste der physischen Adressen von Chunks, die zu den Chunk- und Root-Bäumen gehören, in der gespeichert Superblock.[90]

Superblock-Spiegel werden an festen Orten aufbewahrt:[91] 64 KiB in jedes Blockgerät, mit zusätzlichen Kopien bei 64 MiB, 256 GiB und 1 PiB. Wenn ein Superblock-Spiegel aktualisiert wird, ist es Generationsnummer wird erhöht. Beim Mounten wird die Kopie mit der höchsten Generationsnummer verwendet. Alle Superblock-Spiegel werden im Tandem aktualisiert, mit Ausnahme des SSD-Modus, bei dem die Aktualisierungen zwischen den Spiegeln abwechseln, um einen gewissen Verschleißausgleich zu erzielen.

Kommerzielle Unterstützung[edit]

Unterstützt[edit]

Nicht länger unterstützt[edit]

Siehe auch[edit]

  1. ^ ein b Dies ist die Größenbeschränkung der Btrfs auf der Festplatte. Das Limit wird auf 64-Bit-Systemen aufgrund der internen Limits des Linux-Kernels auf 8 EiB und auf 32-Bit-Systemen auf 2 EiB reduziert, sofern es sich nicht um Kernel handelt CONFIG_LBD Die Konfigurationsoption (verfügbar seit der Kernel-Serie 2.6.x) ist aktiviert, um diese Kernel-Grenzwerte zu entfernen.[101][102]
  2. ^ Jedes Element in Btrfs hat eine 64-Bit-Kennung, was bedeutet, dass die meisten Dateien, die in einem Btrfs-Dateisystem vorhanden sein können, 2 sind64.

Verweise[edit]

  1. ^ “Btrfs Contributors at kernel.org”. kernel.org. 18. Januar 2016. Abgerufen 20. Januar 2016.
  2. ^ ein b “Suse-Dokumentation: Speicherverwaltungshandbuch – Unterstützung großer Dateien unter Linux”. SUSE. Abgerufen 12. August 2015.
  3. ^ ein b c d Mason, Chris. “Btrfs Design”. Btrfs Wiki. Abgerufen 8. November 2011.
  4. ^ Jonathan Corbet (26. Juli 2010). “Dateierstellungszeiten”. LWN.net. Abgerufen 15. August 2015.
  5. ^ “Format auf der Festplatte – btrfs Wiki”. btrfs.wiki.kernel.org.
  6. ^ ein b “btrfs Wiki”. kernel.org. Abgerufen 19. April 2015.
  7. ^ ein b “Linux_4.14 – Linux Kernel Newbies”. kernelnewbies.org.
  8. ^ ein b c d McPherson, Amanda (22. Juni 2009). “Ein Gespräch mit Chris Mason über BTRfs: das Dateisystem der nächsten Generation für Linux”. Linux Foundation. Archiviert von das Original am 27. Juni 2012. Abgerufen 2009-09-01.
  9. ^ ein b c “Deduplizierung”. kernel.org. Abgerufen 19. April 2015.
  10. ^ “ReactOS 0.4.1 veröffentlicht”. reactos.org. Abgerufen 11. August 2016.
  11. ^ http://streaming.oracle.com/ebn/podcasts/media/20209545_Oracle-Linux-7.mp4
  12. ^ ein b Henson, Valerie (31. Januar 2008). Chunkfs: Schnelle Überprüfung und Reparatur des Dateisystems. Melbourne, Australien. Ereignis tritt um 18m 49s auf. Abgerufen 5. Februar 2008. Es heißt Butter FS oder B-Tree FS, aber alle coolen Kids sagen Butter FS
  13. ^ “Linux-Kernel-Commit zur Änderung des Stabilitätsstatus in fs / btrfs / Kconfig”. Abgerufen 8. Februar 2019.
  14. ^ “22.2 Über das Btrfs-Dateisystem”. web.archive.org. 28. April 2018. Abgerufen 27. Januar 2021.
  15. ^ Kerner, Sean Michael (30. Oktober 2008). “Ein besseres Dateisystem für Linux?”. InternetNews.com. Archiviert vom Original am 8. April 2011. Abgerufen 27. August 2020.
  16. ^ ein b Rodeh, Ohad (2007). B-Bäume, Schatten und Klone (PDF). USENIX Linux Storage & Filesystem Workshop. Ebenfalls Rodeh, Ohad (2008). “B-Bäume, Schatten und Klone”. ACM-Transaktionen im Speicher. 3 (4): 1–27. doi:10.1145 / 1326542.1326544.
  17. ^ ein b “Führende Btrfs-Dateisystementwickler treten Facebook bei”. phoronix.com. Abgerufen 19. April 2015.
  18. ^ Paul, Ryan (13. April 2009). “Diskussionsteilnehmer denken beim Linux Collaboration Summit über den Kernel nach”. Ars Technica. Archiviert von das Original am 17. Juni 2012. Abgerufen 2009-08-22.
  19. ^ Ts’o, Theodore (1. August 2008). “Re: reiser4 für 2.6.27-rc1”. Linux Kernel (Mailingliste). Abgerufen 31. Dezember 2010.
  20. ^ “Entwicklungszeitleiste”. Btrfs Wiki. 11. Dezember 2008. Archiviert von das Original am 20. Dezember 2008. Abgerufen 5. November 2011.
  21. ^ Wuelfing, Britta (12. Januar 2009). “Kernel 2.6.29: Corbet sagt Btrfs Next Generation Filesystem”. Linux Magazin. Abgerufen 5. November 2011.
  22. ^ ein b “Red Hat Enterprise Linux 6-Dokumentation: Technologievorschau”. Archiviert von das Original am 28. Mai 2011. Abgerufen 21. Januar 2011.
  23. ^ “Fedora Weekly News Issue 276”. 25. Mai 2011.
  24. ^ “Debian 6.0” Squeeze “veröffentlicht” (Pressemitteilung). Debian. 6. Februar 2011. Abgerufen 8. Februar 2011. Unterstützung wurde auch für die Dateisysteme ext4 und Btrfs hinzugefügt …
  25. ^ ein b “Linux Kernel 3.0, Abschnitt 1.1. Btrfs: Automatische Defragmentierung, Scrubbing, Leistungsverbesserungen”. kernelnewbies.org. 21. Juli 2011. Abgerufen 5. April 2016.
  26. ^ Leemhuis, Thorsten (21. Juni 2011). “Kernel Log: Coming in 3.0 (Teil 2) – Dateisysteme”. Das H öffnen. Abgerufen 8. November 2011.
  27. ^ Varghese, Sam. “iTWire”. ITWire.com. Abgerufen 19. April 2015.
  28. ^ “Unbreakable Enterprise Kernel Release 2 wurde veröffentlicht”. Abgerufen 8. Mai 2019.
  29. ^ “SLES 11 SP2 Versionshinweise”. 21. August 2012. Abgerufen 29. August 2012.
  30. ^ “Versionshinweise zu SUSE Linux Enterprise Server 12”. 5. November 2015. Abgerufen 20. Januar 2016.
  31. ^ ein b “Versionshinweise zu Red Hat Enterprise Linux 7.4, Kapitel 53: Veraltete Funktionen”. 1. August 2017. Archiviert von das Original am 8. August 2017. Abgerufen 15. August 2017.
  32. ^ ein b “Überlegungen zur Einführung von RHEL 8”. Produktdokumentation für Red Hat Enterprise Linux 8. roter Hut. Abgerufen 9. Mai 2019.
  33. ^ “Btrfs kommt zu Fedora 33”. Fedora Magazine. 24. August 2020. Abgerufen 25. August 2020.
  34. ^ ein b c “Btrfs Wiki: Funktionen”. btrfs.wiki.kernel.org. 27. November 2013. Abgerufen 27. November 2013.
  35. ^ “Btrfs Wiki: Changelog”. btrfs.wiki.kernel.org. 29. Mai 2019. Abgerufen 27. November 2013.
  36. ^ “Manpage btrfs-check”.
  37. ^ “Verwenden von Btrfs mit mehreren Geräten”. kernel.org. 7. November 2013. Abgerufen 20. November 2013.
  38. ^ “Kompression”. kernel.org. 25. Juni 2013. Abgerufen 1. April 2014.
  39. ^ “Btrfs: Unterstützung für Inode-Eigenschaften hinzufügen”. kernel.org. 28. Januar 2014. Abgerufen 1. April 2014.
  40. ^ “btrfs: Readonly Snapshots”. Abgerufen 12. Dezember 2011.
  41. ^ “Sparen Sie Speicherplatz unter Linux, indem Sie Dateien auf Btrfs und OCFS2 klonen.”. Abgerufen 1. August 2017.
  42. ^ “Wiki FAQ: Welche Prüfsummenfunktion verwendet Btrfs?”. Btrfs Wiki. Abgerufen 15. Juni 2009.
  43. ^ “Btrfs Hilights in 5.5: Neue Hashes”. Abgerufen 29. August 2020.
  44. ^ ein b “Btrfs Progs Release 4.6”. Abgerufen 1. August 2017.
  45. ^ Mason, Chris (12. Januar 2009). “Btrfs Changelog”. Archiviert von das Original am 29. Februar 2012. Abgerufen 12. Februar 2012.
  46. ^ ein b c Corbet, Jonathan (11. Juli 2012), Btrfs senden / empfangen, LWN.netabgerufen 14. November 2012
  47. ^ “Btrfs Wiki: Inkrementelle Sicherung”. 27. Mai 2013. Abgerufen 27. November 2013.
  48. ^ ein b Jansen, Arne (2011), Btrfs-Subvolume-Kontingentgruppen (PDF), Strato AGabgerufen 14. November 2012
  49. ^ btrfs (16. Juli 2016). “RAID 5/6”. kernel.org. Abgerufen 1. Oktober 2016.
  50. ^ Corbet, Jonathan (2. November 2011). “Ein btrfs-Update auf der LinuxCon Europe”. Abgerufen 12. Februar 2012.
  51. ^ Mazzoleni, Andrea. “btrfs: lib: raid: Neue RAID-Bibliothek, die bis zu sechs Paritäten unterstützt”. Abgerufen 16. März 2014.
  52. ^ “Btrfs Projektideen”. 21. Februar 2013. Abgerufen 21. Februar 2013.
  53. ^ ein b c d Aurora, Valerie (22. Juli 2009). “Eine kurze Geschichte von btrfs”. LWN.net. Abgerufen 5. November 2011.
  54. ^ Hilzinger, Marcel (22. April 2009). “Zukunft von Btrfs gesichert”. Linux Magazin. Abgerufen 5. November 2011.
  55. ^ Corbet, Jonathan (5. Mai 2009). “Die zwei Seiten von reflink ()”. LWN.net. Abgerufen 17. Oktober 2013.
  56. ^ ein b “UseCases – btrfs Dokumentation”. kernel.org. Abgerufen 4. November 2013.
  57. ^ “btrfs: Erlaube das Klonen von Dateien mit mehreren Subvolumes”. github.com. Abgerufen 4. November 2013.
  58. ^ “Symlinks-Referenznamen, Hardlinks-Referenz-Metadaten und Reflinks-Referenzdaten”. pixelbeat.org. 27. Oktober 2010. Abgerufen 17. Oktober 2013.
  59. ^ Meyering, Jim (20. August 2009). “GNU coreutils NEWS: Bemerkenswerte Änderungen in Release 7.5”. savannah.gnu.org. Abgerufen 30. August 2009.
  60. ^ Scrivano, Giuseppe (1. August 2009). “cp: akzeptiere die Option –reflink”. savannah.gnu.org. Abgerufen 2. November 2009.
  61. ^ ioctl_fideduperange(2) – Linux-Programmierhandbuch – Systemaufrufe
  62. ^ ein b c d “SysadminGuide – Btrfs-Dokumentation”. kernel.org. Abgerufen 31. Oktober 2013.
  63. ^ ein b c “5.6 Erstellen von Subvolumes und Snapshots [needs update]””. oracle.com. 2013. Abgerufen 31. Oktober 2013.
  64. ^ “Gotchas – btrfs Wiki”. btrfs.wiki.kernel.org.
  65. ^ ein b “5.7 Verwenden der Sende- / Empfangsfunktion”. oracle.com. 2013. Abgerufen 31. Oktober 2013.
  66. ^ ein b c d Mason, Chris (25. Juni 2015). “Konvertierung von Ext3 (Btrfs-Dokumentation)”. kernel.org. Abgerufen 22. April 2016.
  67. ^ “btrfs-convert (8) Handbuchseite”. Abgerufen 24. April 2018.
  68. ^ “Seed-Gerät”.
  69. ^ Mason, Chris (5. April 2012), Btrfs-Dateisystem: Status und neue Funktionen, Linux Foundationabgerufen 16. November 2012[permanent dead link]
  70. ^ McPherson, Amanda (22. Juni 2009). “Ein Gespräch mit Chris Mason über BTRfs: das Dateisystem der nächsten Generation für Linux”. Linux Foundation. Archiviert von das Original am 27. Juni 2012. Abgerufen 9. Oktober 2014. In zukünftigen Versionen planen wir, Online-Fsck, Deduplizierung, Verschlüsselung und andere Funktionen hinzuzufügen, die schon lange auf den Wunschzettel von Administratoren stehen.
  71. ^ Sterba, David. “Authentifizierte Dateisysteme mit HMAC (SHA256)”. Lore.Kernel.org. Abgerufen 25. April 2020.
  72. ^ “Btrfsck – btrfs Wiki”. btrfs.wiki.kernel.org.
  73. ^ “Wiederherstellen – btrfs Wiki”. btrfs.wiki.kernel.org.
  74. ^ “Problem FAQ – btrfs Wiki”. kernel.org. 31. Juli 2013. Abgerufen 16. Januar 2014.
  75. ^ “kernel / git / torvalds / linux.git: Dokumentation: Dateisysteme: Hinzufügen neuer btrfs-Mount-Optionen (Linux-Kernel-Quellbaum)”. kernel.org. 21. November 2013. Abgerufen 6. Februar 2014.
  76. ^ “Mount-Optionen – btrfs Wiki”. kernel.org. 12. November 2013. Abgerufen 16. Januar 2014.
  77. ^ Reiser, Hans (7. Dezember 2001). “Re: Ext2-Verzeichnisindex: ALS-Papier und Benchmarks”. ReiserFS-Entwickler-Mailingliste. Abgerufen 28. August 2009.
  78. ^ Mason, Chris. “Acp”. Persönliche Oracle-Webseite. Abgerufen 5. November 2011.
  79. ^ Fasheh, Mark (9. Oktober 2012). “btrfs: erweiterte Inode-Refs”. Archiviert von das Original am 15. April 2013. Abgerufen 7. November 2012.
  80. ^ Torvalds, Linus (10. Oktober 2012). “Pull btrfs Update von Chris Mason”. git.kernel.org. Archiviert von das Original am 15. April 2013. Abgerufen 7. November 2012.
  81. ^ Larabel, Michael (24. Dezember 2010). “Benchmarks der Btrfs Space Cache Option”. Phoronix. Abgerufen 16. November 2012.
  82. ^ “FAQ – btrfs Wiki: Welche Prüfsummenfunktion verwendet Btrfs?”. Das btrfs-Projekt. Abgerufen 22. November 2020.
  83. ^ ein b Bierman, Margaret; Grimmer, Lenz (August 2012). “Wie ich die erweiterten Funktionen von Btrfs verwende”. Abgerufen 20. September 2013.
  84. ^ Salter, Jim (15. Januar 2014). “Bitrot and Atomic COWs: In” Next-Gen “-Dateisystemen”. Ars Technica. Abgerufen 15. Januar 2014.
  85. ^ Coekaerts, Wim (28. September 2011). “Btrfs Scrub – Korrigieren Sie bitte Korruptionen mit Spiegelkopien!”. Abgerufen 20. September 2013.
  86. ^ “Manpage / MKFS.BTRFS – BTRFS Wiki”.
  87. ^ Mason, Chris; Rodeh, Ohad; Bacik, Josef (9. Juli 2012), BTRFS: Das Linux B-Tree-Dateisystem (PDF), IBM Researchabgerufen 12. November 2012
  88. ^ Mason, Chris (30. April 2008). “Unterstützung für mehrere Geräte”. Btrfs Wiki. Archiviert von das Original am 20. Juli 2011. Abgerufen 5. November 2011.
  89. ^ Bartell, Sean (20. April 2010). “Re: Wiederherstellen der BTRFS-Partition”. linux-btrfs (Mailingliste).
  90. ^ “Fedora 33 ist offiziell hier!”. 27. Oktober 2020. Abgerufen 28. Oktober 2020.
  91. ^ “Oracle unterstützt jetzt Btrfs RAID5 / 6 auf seinem unzerbrechlichen Unternehmenskern – Phoronix”. Phoronix.com.
  92. ^ “Verwalten von Btrfs in Oracle Linux 8”. docs.oracle.com.
  93. ^ “SUSE bekräftigt die Unterstützung für Btrfs [LWN.net]””. LWN.net.
  94. ^ “Versionshinweise | SUSE Linux Enterprise Server 15 GA”. Suse.com.
  95. ^ “DiskStation Manager – Knowledge Base | Synology Inc”. Synology.com.
  96. ^ “Unterstützung für ReactOS-Dateisysteme”. reactos.org/wiki/.
  97. ^ “TrBtrfs ist in RHEL | Hacker News veraltet”. news.ycombinator.com.
  98. ^ “Red Hat scheint ihre Btrfs-Hoffnungen aufzugeben – Phoronix”. www.phoronix.com.
  99. ^ Andreas Jaeger (15. Februar 2005). “Unterstützung für große Dateien unter Linux”. users.suse.com. Abgerufen 12. August 2015.
  100. ^ “Hilfe zur Linux-Kernelkonfiguration für CONFIG_LBD in 2.6.29 auf x86”. kernel.xc.net. Archiviert von das Original am 6. September 2015. Abgerufen 12. August 2015.

Externe Links[edit]


after-content-x4