staging.inyokaproject.org

Dir ist aber schon klar, daß du (derzeit noch) eine eigene /boot Partition brauchst?

Da ich Dich erwähnt habe, ja.

Was Ihr aber alle nicht geschrieben habt und was ich leider nicht beachtet habe, ist, dass fehlerfreies Bezeichnen von Partitionen in der fstab die Voraussetzung für korrektes Booten ist. 😈

Label="xyz" != LABEL="xyz"

Lernen durch Schmerzen. Ab und zu sollte man seine eigene Schreibe kritsch prüfen, vor allem in Systemfiles. Das mit dem Einkompilieren in den Kernel wollte ich mir eigentlich sparen, in dem Fall kommt man wohl wirklich um eine ext-Partition nicht drumrum. Aber lieber eine Partition mehr, als 1-2 Tage an einem Kernel frickeln, der in dieser Zeit evtl. schon wieder obsolet ist.

Obwohl so ein Kompilerlauf mein bevorzugtes Mittel zur Leistungsmessung ist.

also bei mir geht alles ☺ hab mir jetzt Qt downgeloaddet und werde das nun mal im btrfs kompilieren ☺

Klasse, nach der Entfernung meines Dummsinnsfehlers funkt bei mir auch alles 1a. Jetzt kann man eigentlich damit anfangen, das System ein wenig zu quälen. Da bei mir noch alles auf defaults steht, glaube ich, es wäre an der Zeit, mal die phoronix-testsuite zu ziehen. Und dann mal schauen, was die Jungs wieder an Irrsinn "gemessen" haben. Ich liebe eigene Tests, da kann ich dann wenigstens testen, was ich wirklich wissen möchte.

Eigentlich ist die Suite ja gut.

Ich werde jetzt mal im Selbstversuch mit eine paar der Mount-Optionen spielen. Für mich besonders interessant klangen:

• nodatasum - Do not checksum data. Means bit flips and bit rot might go undetected, but allows for slightly faster operation since data checksum does not have to be calculated. On most modern CPUs this option does not result in any reasonable performance improvement.

• nodatacow - Do not copy-on-write data. datacow is used to ensure the user either has access to the old version of a file, or to the newer version of the file. datacow makes sure we never have partially updated files written to disk. nodatacow gives slight performance boost by directly overwriting data (like ext^[234]), at the expense of potentially getting partially updated files on system failures. Performance gain is usually < 5% unless the workload is random writes to large database files, where the difference can become very large

• compress - Enable compression

Die ersten Beiden versprechen nicht Viel, compress scheint dagegen interessant.

So, ohne das ich jetzt als Basher gehauen werde: BTRFS ist langsam. Und zwar wie erwartet, ca. 20% bi 25% ohne Optimierungen beim Schreiben. Datenmix einer /home-Partition Größe 12 G. Schreiben auf neue, nicht optimierte Ext4 3 min. Schreiben auf neue, nicht optimierte Partition BTRFS 3:50 min. Das ist das Negative. Das Positive ist, dass ich, noch unoptimiert, noch nie ein Dateisystem hatte, was so schnell und ohne Einbrüche liest. Da kann ich noch keine konkreten Zahlen sagen, es fühlt sich aber gut an.

Mounte das Ganze mal mit compress, das sollte Abhilfe schaffen. Zumindest kommen mir Schreibvorgänge so flotter vor als unter Ext4.

Kommt Zeit, kommt Rat. Ja, compress beschleunigt eine ganze Menge, vor allem bei größeren Files, da sich die Menge der physikalisch geschriebenen Daten bei komprimierbaren Files deutlich vermindert.

Wie gesagt, erstmal bleibt das so, bis phoronix unten ist. 3G fehlen noch. Dann wird gemessen und nach und nach eingeschaltet. Bei kleine Dateien erwarte ich nicht so viel, das war schon bei meinem ersten Test unter Arch so. Aber für Filesysteme wie /, /usr usw erwarte ich schon eine ganze Menge im Normalbetrieb.

hm ja

Qt ist kompiliert ☺

agaida schrieb:

So, ohne das ich jetzt als Basher gehauen werde: BTRFS ist langsam.

Ich habe gestern unter U. 9.04/ ext3 von einer Partition zur anderen derselben Festplatte kopiert (Gnome) und dabei nur 2-3 MB/s bekommen. Intern, SATA.

Das ist doch noch relativ schnell;) IMHO geht bei solchen Aktionen die meiste Zeit beim Positionieren drauf. Bei mir waren es neue Partitionen auf unabhängigen Platten. Ich denke mal, das ist dann irgendwie aussagefähiger (Ach so, auf die beteiligten Platten hatte nichts anderes Zugriff.) Dieses Ergebnis hatte ich aber schon erwartet.

Ich wollte das heute eigentlich mal ein wenig qualifizierter messen, aber leider ist die ach so tolle Phoronix-Suite in diesem Punkt total untauglich. Jetzt muss ich mir doch eigene Gedanken machen. Aber wie schon geschrieben, auf Partitonen, auf denen hauptsächlich geschrieben wird, dürfte BTRFS einen richtig schlanken Fuss. Interessant wäre jetzt nur noch der direkte Vergleich mit dem Mörder-Dateisystem, aber das ist ja noch nicht offiziell.

Und der ganze Aufwand nur, weil ZFS aus lizenzrechtlichen Grüneden nicht in den Kernel darf 😢

Dennoch, ext4 ist ja damit wohl schon gestorben, ehe es mal richtig verbreitet ist?

Viele Grüße,

Ingo

Totgesagte leben bekanntlich länger und es gibt einige Gründe für ein noch langes Leben von ext4.

• ohne viel Aufwand kannst Du ext4 → ext2 deluxe schrauben, die Performance beim Schreiben ist meines Wissens unerreicht.

• btrfs und reiser 4 können zwar einige schicke Sachen, fragmentieren aber relativ stark (o.k. dafür kann man auch online defragmentieren)

• die Entwicklung ist ja mit ext4 nicht abgeschlossen, so was wie Snapshots, transparente Kompression etc. pp können ja noch kommen

• bitte jetzt nich hauen, aber Stabilität, wenn man dann wirklich will (data=journal)

Und der absolute Hauptgrund: ext2, ext3, reiser, xfs ... leben auch alle noch und sind nicht totzukriegen. Aber Du hast schon recht, der Ubuntu-Neuling, der unbelastet an die Sache herangeht, wird btrfs nehmen, weil es vorgeschlagen wird. Ich kann mir (momentan) wirklich nicht vorstellen, meine Server auf btrfs umzustellen. Aber als reines Desktop-FS wird btrfs sicher eine recht große Nummer.

Aber es wird endlose Diskussionen von von "Hardcore-Freakz" und "Hackerz" geben und es werden neue, langwierige Glaubenskriege ausbrechen. Irgendwie erinnere ich mich noch an die "Diktatur-Diskussion" wg. Buttons auf der linken Seite.

Die nächste interessante Frage wäre, was passiert, wenn bei ZFS die Gründe wegfallen würden?

Allen aktuell noch vorhandenen Problemen zum Trotz: ich habe durchaus das Gefühl daß das System mit BTRFS etwas flotter reagiert. Das merke ich hauptsächlich an den schneller dargestellten Ordnerinhalten bei größeren Verzeichnissen, aber auch bei anderen Aktionen. Letztlich ist auch die Integration in Maverick sehr fein, das dürfte dafür sorgen daß die Arbeiten deutlich schneller vorankommen.

Mit aktivierter Kompression wird Dich Dein Gefühl nicht trügen, rein lesen sollte ohne Uhr merkbar sein.