systemd in openSUSE-factory-12.1 November Release

[ralul]

Du weisst aber schon, dass der Hauptentwickler von Btrfs schon beim Mörder in Lohn und Brot stand? So gesehen ist:
 Btrfs = ZFS+Reiser4-Reiser4SemantikFeatures

[reddark]

Du weisst aber schon, dass der Hauptentwickler von Btrfs schon beim Mörder in Lohn und Brot stand?

Werden wir jetzt alle Mörder? (the Devil in uns ) .... Auch ein verwirrtes Genie kann gute Ideen haben!!

[agaida]

Ich will das nicht alles nicht werten. Die Mitarbeiter von Einstein haben die Relativitätstheorie auch nicht entscheidend verändert. Den menschlichen Apekt mal ausser acht lassend, auch reiserfs wird weiterentwickelt. Ich sehe im Fall butterfs so einige Probleme:

Redhat beauftragte im Q2/2010 Edward Shishkin, einen der ursprünglichen Reiser4 Entwickler, mit einem Codereview. Shishkins Schluss war, dass das Design fehlerhaft ist, da dem ursprünglichen Algorithmus in Kernpunkten nicht gefolgt wird. Die Designfehler führen dazu, dass in speziellen Fällen der Plattenplatz ausgehen kann, obwohl genügend Platz vorhanden ist.[16][17][18]

Eine stabile btrfs-Version (mit dem endgültigen Datenformat - Version 1.0) war ursprünglich für 2008 zur Veröffentlichung vorgesehen, wurde jedoch bisher (Mai 2011) noch nicht veröffentlicht. Nichtsdestoweniger ist die Unterstützung bereits in die Hauptversion des Linux-Kernels aufgenommen (seit Version 2.6.29-rc1). Bei einigen Linux-Distributionen steht das Dateisystem bereits offiziell bei der Installation zur Auswahl.

Quelle Wikipedia

Warten wir einfach ein paar Jahre ab, bis die sich auf ein Datenformat geeinigt haben und die Prozesse im Dateisystem ausgereift sind. Ich weigere mich einfach, mir um unausgegorenen Scheiss Gedanken zu machen. Vielleicht liegt es am Alter - ich lebe hier und heute. Hier und heute werde ich den Teufel tun und auf halbfertige Dateisysteme setzten. Das sehe ich genauso wie bei Pizza, die esse ich auch nicht ungebacken.

[ralul]

In dem Streit letztes Jahr ging es nicht um das Datenformat, sondern um den Algorithmus den freien Plattenplatz zu verteilen: Shishkin kritisierte, dass das nicht rein nach Dogmen der BalancedTrees-Informatiker-Idee implementiert ist. Chris Mason, der Btrfs vebockt, argumentierte, dass es in praktischen Anwendungsfällen in einem CopyOnWrite System gerechtfertigt ist, in Spezialfällen abzuweichen um Geschwindigkeit beim Schreiben rauszulocken.

Ich hatte vor einem Jahr den Eindruck, dass Shishkin wohl ein wenig pedantisch und eifersüchtig hier kritisiert, weil er im Gegensatz zu seinem früheren Kollegen nicht so einen guten Job gefunden hat.

Allerdings hört man heute, dass wohl das eintritt, was Shishkin vor einem Jahr in seiner Kritik vorausgesagt hat, Probleme mit fast vollen Platten:

Hi Jeff,

The day after the openSUSE conference, Jos showed me his laptop and a
problem with it under the most recent Tumbleweed kernel (and older
kernels as well.)

He is copying a very large (3Gb) file to his btrfs partition from a USB
external drive (running ext3) such that if it succeeds, the partition
will almost be full (only a few Mb left).  This should be fine, but it
almost kills the system, slowing responsiveness down to nothing being
possible to do at all on the box until the copy completes 15+ minutes
later.  It is possible to eventually interrupt the copy, and when that
happens, the system returns back to life.

Copying the other way (from the btrfs partition to the USB disk), works
absolutly fine, so it doesn't seem like the system is hurting from
memory pressure on anything else.

Is this a currently-known issue on btrfs when the filesystem is almost
out of space and it just takes forever to find empty blocks in which to
put things, or is it something that we should log in a bugzilla entry
and try to get resolved?

thanks,

greg k-h

[agaida]

Krümelkackerei zahlt sich an einigen wenigen Stellen im System durchaus aus. Das Dateisystem sollte nicht nach dem Prinzip: Shure it destroys your data, but look how fast it is. aufgebaut sein. Das hatten wir vor knapp 30-40 Jahren schon mal. Es hat sich gezeigt das Optimismus nicht unbedingt der beste Weg für verantwortungsvollen Umgang mit Daten ist.

Das nehme ich mal als so gegeben hin und denke nochmal daran, wie lange es gedauert hat, bis ext4 als sicher in den Köpfen angekommen war. Von daher sollen die Jungens bei Fedora und Ubuntu den Feldtest machen. Wenn das dann so 2 Jahre ohne nennenswerte Probleme läuft, dann darf man mir das vorschlagen. Bis dahin sollen deren Daten dran glauben, das tangiert mich dann eher peripher. Und bis dahin hilft moderne Technik, die eventuell nicht so schnellen, aber sicheren Algorithmen zu beschleunigen.

[ralul]

Home würde ich auch noch nicht Btrfs machen. Aber ein schnell ersetzbares Betriebsystem:
siduction-advanced: mit 30GiB, was nicht überlaufen kann, würde micht reizen, mit Snapshotfunktion!
Feldtest kann man allerdings auch freiwillig mit openSUSE-12.1 machen ...