Mit Subvolumes, Snapshots und RAID bietet btrfs ähnliche Funktionen wie die im Kernel schon enthaltenen Multi Device und Logical Volume Manager. An sich sind solche Doppelgleisigkeiten im Kernel unerwünscht, im Falle von btrfs wurden sie aber akzeptiert. Der Grund: einerseits ermöglicht die direkte Integration von RAID-Funktionen in den Dateisystemtreiber aufgrund der Prüfsummen eine noch höhere Datensicherheit, andererseits haben die btrfs-Entwickler glaubhaft nachweisen können, dass die btrfs-Snapshots wesentlich effizienter sind als die von LVM.
Hmm, das BTRF selbst bessere/schnellere Snapshots anlegen kann als LVM ist ja wohl klar. LVM kennt das zugrundeliegende Dateisystem nicht und kann daher nur auf Blockebene arbeiten.
Was war das doch für ein Geschrei als ReiserFS4 vorgestellt wurde. Da hat man unendliche viele Ausreden gefunden, warum ReiseFS 4 auf keinen Fall selbst Snapshots anlegen darf oder warum die Kompression/RAID-Funktion ausgegliedert werden muss. Alles sollte von der darüberliegenden Schicht erledigt werden und nicht vom Dateisystem selbst - egal wieviel Performance das dann kostet.
Kaum kommt Oracle, ist das natürlich alles kein Problem mehr. Da darf dann das Dateisystem all die Funktionen selbst implementieren. Würde ja sonst Performance kosten.
Irgendwie habe ich das Gefühl, dass die Linux Entwickler immer mehr zu Politikern werden.
Das war schon immer so und in letzter Zeit wird es immer mehr sichtbar, da immer mehr Entwickler des Kernels bei wenigen Global-Playern angestellt sind.
Im Artikel steht, dass die nachweislich höhere Performance der Grund war, wieso btrfs so akzeptiert wurde. Bei ReiserFS4 kann ich mich an Performance Vergleiche allerdings nicht erinnern.
Von M wie Meikel am Do, 26. August 2010 um 18:08 #
Das hat nichts mit der Größe seines Brötchengebers zu tun, sondern mit dem Nasenfaktor.
Hans Reiser hat den Kernel-Göttern was Fertiges vor die Füße geknallt, da haben sie ihn gezeigt, wer am längeren Hebel sitzt. Ähnliche Spielchen gab man auch bei CFS. Chris Mason hat das einfach schlauer angestellt.
Und ich bin mir sicher: käme er heute mit einem ersten BtrFs-Prototyp an, würden ihn die Kernel-Götter abblitzen lassen. Schließlich ist Oracle jetzt eine "böse" Firma.
Ja BFS ist besser. Aber Con Kolivas arbeitet ja wieder dran und seit den Zen-Kernel-Patches für 2.6.31 läuft bei mir wieder Cons scheduler
Dem BFQ I/O scheduler von Fabio Checconi scheint es aber nicht so gut zu gehen, patches gibt's nur bis 2.6.30 und auch Zen hat ihn nur bis 2.6.32 portiert Wobei ich glaube gehört zu haben, dass die Verbesserungen des BFQ in den CFQ eingeflossen sind, bin mir da aber nicht wirklich sicher.
Der BFS ist schneller auf PCs Der CFS ist auf Servern schneller Molnar hat auf einer Maschiene mit 48 cores getestet, also ich habe so etwas noch nicht in meinem Notebook
Ich merke den Unterschied, vor allem bei Audio/Video-Konvertierung (BFS) und beim Übertragen von Daten auf USB o. ä. (BFQ). Außerdem ist der Vergleich vom letzten Jahr. BFS wurde in der Zwischenzeit von Grund auf neu geschrieben, der Vergleich also hinfällig.
Hmm, das BTRF selbst bessere/schnellere Snapshots anlegen kann als LVM ist ja wohl klar. LVM kennt das zugrundeliegende Dateisystem nicht und kann daher nur auf Blockebene arbeiten.
Was war das doch für ein Geschrei als ReiserFS4 vorgestellt wurde. Da hat man unendliche viele Ausreden gefunden, warum ReiseFS 4 auf keinen Fall selbst Snapshots anlegen darf oder warum die Kompression/RAID-Funktion ausgegliedert werden muss. Alles sollte von der darüberliegenden Schicht erledigt werden und nicht vom Dateisystem selbst - egal wieviel Performance das dann kostet.
Kaum kommt Oracle, ist das natürlich alles kein Problem mehr. Da darf dann das Dateisystem all die Funktionen selbst implementieren. Würde ja sonst Performance kosten.
Irgendwie habe ich das Gefühl, dass die Linux Entwickler immer mehr zu Politikern werden.
Das war schon immer so und in letzter Zeit wird es immer mehr sichtbar, da immer mehr Entwickler des Kernels bei wenigen Global-Playern angestellt sind.
Im Artikel steht, dass die nachweislich höhere Performance der Grund war, wieso btrfs so akzeptiert wurde.
Bei ReiserFS4 kann ich mich an Performance Vergleiche allerdings nicht erinnern.
Das hat nichts mit der Größe seines Brötchengebers zu tun, sondern mit dem Nasenfaktor.
Hans Reiser hat den Kernel-Göttern was Fertiges vor die Füße geknallt, da haben sie ihn gezeigt, wer am längeren Hebel sitzt. Ähnliche Spielchen gab man auch bei CFS. Chris Mason hat das einfach schlauer angestellt.
Und ich bin mir sicher: käme er heute mit einem ersten BtrFs-Prototyp an, würden ihn die Kernel-Götter abblitzen lassen. Schließlich ist Oracle jetzt eine "böse" Firma.
Was du alles weißt.
>> Ähnliche Spielchen gab man auch bei CFS
Ja BFS ist besser. Aber Con Kolivas arbeitet ja wieder dran und seit den Zen-Kernel-Patches für 2.6.31 läuft bei mir wieder Cons scheduler
Dem BFQ I/O scheduler von Fabio Checconi scheint es aber nicht so gut zu gehen, patches gibt's nur bis 2.6.30 und auch Zen hat ihn nur bis 2.6.32 portiert
Wobei ich glaube gehört zu haben, dass die Verbesserungen des BFQ in den CFQ eingeflossen sind, bin mir da aber nicht wirklich sicher.
Ich habe gerade festgestellt, dass der BFQ im Zen 2.6.35 wieder drin ist!
*draufloskompilier*
Naja, kommt drauf an wem man glaubt?
In den Benchmarks von Kolivas ist BFS besser als CFS
In den Benchmarks von Molnar ist CFS besser als BFS
http://www.linux-community.de/Internal/Nachrichten/Ingo-Molnar-meldet-sich-zum-Brain-Fuck-Scheduler-zu-Wort
Btw. Ich merk ehrlich gesagt keinen spürbaren Unterschied zwischen CFS und BFS!
Der BFS ist schneller auf PCs
Der CFS ist auf Servern schneller
Molnar hat auf einer Maschiene mit 48 cores getestet, also ich habe so etwas noch nicht in meinem Notebook
Ich merke den Unterschied, vor allem bei Audio/Video-Konvertierung (BFS) und beim Übertragen von Daten auf USB o. ä. (BFQ). Außerdem ist der Vergleich vom letzten Jahr. BFS wurde in der Zwischenzeit von Grund auf neu geschrieben, der Vergleich also hinfällig.