Gentoo Forums

Die meisten haben das bcachefs-Drama vermutlich schon mitbekommen, für diejenigen bei denen das noch nicht der Fall ist hier mal ein Link dazu:
https://linuxnews.de/bcachefs-auf-dem-w ... em-kernel/

Ich habe jetzt einige Tage darüber nachgedacht und finde das sich der Entwickler von bcachefs zurecht gegen das aktuelle System auflehnt. Das ein zwei Wochen langes "Merge Window", welches nur alle 10 bis 11 Wochen zur Verfügung steht, für jemand der so aktiv an einer Software arbeitet wie es hier der Fall ist alles andere als praktikabel ist sollte doch nachvollziehbar sein.
Auf mich wirken die Regeln wie beim Kernel die Entwicklung stattfindet etwas unflexibel.

Gerade im Bezug auf ein Dateisystem muss man nunmal vorsichtig sein. Jedes verlorene Byte ist da meines Erachtens eines zuviel.
und die Regeln des Kernels, also mit Merge Window, Testsuite und alledem ist ja nicht aus jucks und dollerei entstanden sondern hat meistens seinen Ursprung in irgendjemandes verlorenen Daten aufgrund von Bugs.

Der Overstreet kann ja entwickeln. Er sollte sich halt beim Einreichen an Regeln halten und Stabilitätspatches sind ja nie das Problem. Neue ungetestete Features waren in aller Regel immer das Problem wenn es zu Problemen kam.

schmidicom wrote:Ich habe jetzt einige Tage darüber nachgedacht und finde das sich der Entwickler von bcachefs zurecht gegen das aktuelle System auflehnt. Das ein zwei Wochen langes "Merge Window", welches nur alle 10 bis 11 Wochen zur Verfügung steht, für jemand der so aktiv an einer Software arbeitet wie es hier der Fall ist alles andere als praktikabel ist sollte doch nachvollziehbar sein.
Auf mich wirken die Regeln wie beim Kernel die Entwicklung stattfindet etwas unflexibel.

Klingt erstmal altbacken und Streng aber: "Je mehr Menschen zusammenarbeiten, je mehr Regeln braucht man."
Dies bedeutet nicht das man alt und unflexibel wird, es soll nur sicherstellen das man zusammenarbeiten und man sich auf andere Verlassen kann. Wie im Straßenverkehr. Wenn man sich auf Regeln und Verhalten verlassen kann, kann man sich auf anderes konzentrieren.

Wenn nun jeder die Regel nach eigenem Willen aufweichen kann, weiß keiner mehr warum was passiert. Passiert dann was Dummes muss man sich den Wolf suchen.

In diesem Fall ist die Regel einfach dazu da, Fehler zu minimieren und sich auf das Wichtige konzentrieren zu können.

schmidicom wrote:finde das sich der Entwickler von bcachefs zurecht gegen das aktuelle System auflehnt.

Die Regeln mögen unter umständen eine Anpassung benötigen. Aber was nicht geht, sich einfach über die bestehenden Regeln hinwegsetzen und dann wenn man darauf hingewiesen wird sich an die Regeln zu halten diese als unpassend zu beschreiben.
Und das hat kent getan.
Der Bessere weg wäre gewesen, eine Diskussion über eine Änderungen der Regeln vorher anzustoßen.
Ein weiteres Problem ist, dass kent sich schon mehrmals sich einfach über die bestehenden Regeln hinweggesetzt hat und mehrmals darauf hingewiesen wurde.
Und das scheinbar ohne Erfolg da scheinbar keine besserung des Verhaltens von seitens kent zu erkennen ist.

Die Regeln haben sich nicht geändert, seit bcachefs in den Kernel aufgenommen wurde. Wenn es nicht stabil genug ist, dass der Entwickler ständig gegen verstoßen muss (was auch seine Begründung dafür ist), dann hätte es von vornherein nicht in diesem Stadium gepusht werden sollen.

OK, inkompatible Änderung sind ja mal was anderes als neue/verbesserte Funktionen und das man die (egal ob es das im Fall von bcachefs gegeben hätte oder nicht) nicht gutheisst kann ich nachvollziehen. Aber das man in einem Entwicklerzweig nur alle 10/11 Wochen ein zwei Wochen grosses Fenster für neue/verbesserte Funktionen offen lässt wirkt für mich nach wie vor etwas seltsam. Würde man zwei Wochen vor der Freigabe einer neuen Version aus dem Entwicklerzweig solche Änderungen ablehnen dann könnte ich das eher nachvollziehen.

Aber vielleicht geht es bei einem Projekt in der Grösse des Linux-Kernel wirklich nicht mehr anders und dann ist das halt eben so.

schmidicom wrote:OK, inkompatible Änderung sind ja mal was anderes als neue/verbesserte Funktionen und das man die (egal ob es das im Fall von bcachefs gegeben hätte oder nicht) nicht gutheisst kann ich nachvollziehen. Aber das man in einem Entwicklerzweig nur alle 10/11 Wochen ein zwei Wochen grosses Fenster für neue/verbesserte Funktionen offen lässt wirkt für mich nach wie vor etwas seltsam. Würde man zwei Wochen vor der Freigabe einer neuen Version aus dem Entwicklerzweig solche Änderungen ablehnen dann könnte ich das eher nachvollziehen.

Ich glaub du sitzt da ein Missverständnis auf.
Nach meinem Verständnis ist der "linus" branch kein Entwicklerzweig, sondern ein Release zweig. Und es gibt halt ein 2 Wochen fenster wo neue features und andere Änderungen in diesen branch gemerged werden, welche im nächsten release enthalten sein sollen. Und danach gibt es dann ein mehrwöchiges Fenster für bugfixing/Stabilisierung
Die eigentlichen Entwicklung der features/Änderungen erfolgen in separaten branches.

firefly wrote:Ich glaub du sitzt da ein Missverständnis auf.
Nach meinem Verständnis ist der "linus" branch kein Entwicklerzweig, sondern ein Release zweig. Und es gibt halt ein 2 Wochen fenster wo neue features und andere Änderungen in diesen branch gemerged werden, welche im nächsten release enthalten sein sollen. Und danach gibt es dann ein mehrwöchiges Fenster für bugfixing/Stabilisierung
Die eigentlichen Entwicklung der features/Änderungen erfolgen in separaten branches.

Ok, so ergibt das schon mehr Sinn.
Das würde dann ja bedeuten das auch Overstreet seine eigenen branch hat wo er machen kann was er will und wenn dann dieses zweiwöchige Fenster offen ist könnte er alle Änderungen einreichen, richtig?

schmidicom wrote:Ich habe jetzt einige Tage darüber nachgedacht und finde das sich der Entwickler von bcachefs zurecht gegen das aktuelle System auflehnt.

Sehe ich komplett anders. Wenn die Regeln Konsens sind und die Entwicklergemeinde ansonsten damit kein Problem hat, kann nicht ein einzelner daher kommen und sich auflehnen und verlangen, damit durchzukommen. Dann fliegt es zurecht aus dem Kernel, gerade, wenn dieser meint noch gegenüber andere ausfällig werden zu müssen.

schmidicom wrote:

firefly wrote:Ich glaub du sitzt da ein Missverständnis auf.
Nach meinem Verständnis ist der "linus" branch kein Entwicklerzweig, sondern ein Release zweig. Und es gibt halt ein 2 Wochen fenster wo neue features und andere Änderungen in diesen branch gemerged werden, welche im nächsten release enthalten sein sollen. Und danach gibt es dann ein mehrwöchiges Fenster für bugfixing/Stabilisierung
Die eigentlichen Entwicklung der features/Änderungen erfolgen in separaten branches.

Ok, so ergibt das schon mehr Sinn.
Das würde dann ja bedeuten das auch Overstreet seine eigenen branch hat wo er machen kann was er will und wenn dann dieses zweiwöchige Fenster offen ist könnte er alle Änderungen einreichen, richtig?

Genau. Die Entwicklung ist dezentral (Dieses System hat die Entstehung von git beeinflusst) und jeder kann in seinem code/branch machen was er will.
Dann wenn es zusammenkommt und was gemeinsames dabei raus kommen soll, dann muss es nach Regeln laufen. Sonst macht man sich Dinge gegenseitig kaputt (denn nicht alles kann durch ein VCS sauber zusammengeführt werden). Ebenso wissen dann die Prüfer nicht was nun geprüft werden soll oder ob ein Verhalten nun richtig oder falsch ist.

Hat hier eigentlich mal jemand bcachefs unter Gentoo erfolgreich ausprobiert? Wenn ja was ist das Fazit?
Mein letzter Versuch (der zugegeben schon länger her ist), per rsync ein Systembackup darauf wiederherzustellen, endete mit einem Freeze des Systems.

schmidicom wrote:Hat hier eigentlich mal jemand bcachefs unter Gentoo erfolgreich ausprobiert? Wenn ja was ist das Fazit?
Mein letzter Versuch (der zugegeben schon länger her ist), per rsync ein Systembackup darauf wiederherzustellen, endete mit einem Freeze des Systems.

Ich bin ehrlich... angeblich ist ja btrfs oder zfs schon lange stabil aber irgendwie schätze ich Stabilität zu sehr und setze immernoch ext4 für alles ein... außer ich brauch Win-Kompatibilität, weil Dual-Boot, dann halt ntfs-3g.

Max Steel wrote:

schmidicom wrote:Hat hier eigentlich mal jemand bcachefs unter Gentoo erfolgreich ausprobiert? Wenn ja was ist das Fazit?
Mein letzter Versuch (der zugegeben schon länger her ist), per rsync ein Systembackup darauf wiederherzustellen, endete mit einem Freeze des Systems.

Ich bin ehrlich... angeblich ist ja btrfs oder zfs schon lange stabil aber irgendwie schätze ich Stabilität zu sehr und setze immernoch ext4 für alles ein... außer ich brauch Win-Kompatibilität, weil Dual-Boot, dann halt ntfs-3g.

Mit ext3/ext4 habe ich mehrfach ganz üble Erfahrungen gemacht, es ist mir dort zweimal passiert das alle Dateien ohne ihre Ordnerstruktur in lost+found gelandet sind und die restliche Ordnerstruktur zwar noch vorhanden aber komplett leergefegt war.
Ich verwende schon länger wo ich nur kann XFS, das ist mir noch nie kaputt gegangen, ist aber halt auch nicht gerade das modernste/schnellste. Wenigstens hat XFS vor einziger Zeit mal den Support für CopyOnWrite (die nennen das dann "reflink") bekommen.

schmidicom wrote:Mit ext3/ext4 habe ich mehrfach ganz üble Erfahrungen gemacht, es ist mir dort zweimal passiert das alle Dateien ohne ihre Ordnerstruktur in lost+found gelandet sind und die restliche Ordnerstruktur zwar noch vorhanden aber komplett leergefegt war.

Interessant. ist mir bislang noch nie in der Form untergekommen. Es gab mal einzelne Daten die mir verloren gingen während ich Stromverlust hatte. Aber das ist eine ganz andere Geschichte.

schmidicom wrote: Mit ext3/ext4 habe ich mehrfach ganz üble Erfahrungen gemacht, es ist mir dort zweimal passiert das alle Dateien ohne ihre Ordnerstruktur in lost+found gelandet sind und die restliche Ordnerstruktur zwar noch vorhanden aber komplett leergefegt war.

Solche Berichte findet man für alle FS, daher ist das eher weniger ein indikator ob ein FS besser wäre als ein anderes.
In deinem Falle könnte es auch durch Fehler in der HW (Datenträger oder rest des Systems) ausgelöst worden sein und kein Dateisystem Problem an sich.

Kleiner Nachtrag:
Da scheint noch nicht ganz klar zu sein ob bcachefs jetzt wirklich aus dem Kernel fliegt oder nicht.
https://linuxnews.de/wird-bcachefs-im-kernel-bleiben/

Ich habe auch versucht den Artikel zu lesen den Overstreet auf Patreon veröffentlicht hat, muss aber zugeben das ich wenig davon verstanden habe. Wirkt auf mich so als wäre er einerseits der Meinung das sein Code wegen "Fehlern" (wenn es denn Fehler sind) welche in anderen Teilen des Kernels stecken nicht wie erwartet funktioniert hat und das andererseits die aktuellen Regeln ein beheben solcher "Fehler" schwieriger macht als es nötig wäre.
Keine Ahnung ob ich das halbwegs richtig interpretiere und ob er Recht hat kann ich schon mal gar nicht beurteilen. Ich kann nur, aufgrund eigener Lebenserfahrung, den Frust nachvollziehen der aufkommt wenn das eigene Projekt wegen der Fehler anderer nicht so funktioniert wie man sich das vorstellt oder erhofft hat.

Oder man zeigt auf Andere, während man selbst schon genug dokumentierte Fehler produziert. Ist eine Charaktersache.

schmidicom wrote:Ich kann nur, aufgrund eigener Lebenserfahrung, den Frust nachvollziehen der aufkommt wenn das eigene Projekt wegen der Fehler anderer nicht so funktioniert wie man sich das vorstellt oder erhofft hat.

Wenn das eigene Projekt darunter leidet, dass Fehler in anderer Leute code wie in einem OS Projekt wie der Linux Kernel stecken, dann hat man die zu behebenden Bugs meistens schon weitgehend identifiziert und sollte in der Lage sein, diese entsprechend zu beheben oder wenigstens entsprechende Threads darüber aufzumachen.
Ansonsten sieht das nur nach sinnloser Fingerzeigerei und "Schuld" von sich weiserei aus. Wie asturm schon meinte... Charakterfrage.

Das Drama entwickelt sich jetzt in eine Richtung die für Benutzer das Potenzial hat sehr unangenehm zu werden.
Dateisystem Bcachefs bleibt Teil des Linux-Kernels

Jetzt bleibt im Kernel eine Version von bcachefs liegen bei der keine Weiterentwicklung mehr stattfindet und parallel dazu gibt es eine extern gepflegte Version die unter Umständen inkompatible Änderungen am Dateisystem vornimmt. Also in Zukunft muss jede Person die bcachefs verwendet aufpassen was für ein Kernel auf das eigene Dateisystem losgelassen wird.

Toll...

schmidicom wrote:Ich kann nur, aufgrund eigener Lebenserfahrung, den Frust nachvollziehen der aufkommt wenn das eigene Projekt wegen der Fehler anderer nicht so funktioniert wie man sich das vorstellt oder erhofft hat.

Wie der Heise-Artikel schreibt: „weil er von ihnen betreuten Linux-Kernel-Code ohne adäquate Absprache oder gar hinter deren Rücken veränderte.“ - wäre ich auch angepisst. Overstreet hätte ja schlicht auch wahrgenommene Fehler einfach reporten und Patchvorschläge einreichen können. Wie üblich.

schmidicom wrote:Jetzt bleibt im Kernel eine Version von bcachefs liegen bei der keine Weiterentwicklung mehr stattfindet und parallel dazu gibt es eine extern gepflegte Version die unter Umständen inkompatible Änderungen am Dateisystem vornimmt. Also in Zukunft muss jede Person die bcachefs verwendet aufpassen was für ein Kernel auf das eigene Dateisystem losgelassen wird.

Toll...

Naja da wird demnächst halt eine dkms Config und ein ebuild für bcachefs out-of-tree auftauchen und gut ist.
Ist aber vermutlich trotzdem die beste Lösung. Das FS fliegt erstmal nicht einfach so aus dem Kernel. Overstreet hat Zeit sich an die Gepflogenheiten in der Kernel Entwicklung anzupassen und wenn er guten Willen zeigt, das bei zu behalten oder ein mitm Übersetzer und puffer zwischen Overstreet und dem Rest der Kernel Community gefunden wurde, kann die Entwicklung an der Stelle wieder aufgenommen werden und entsprechende fixes und neue Features zu gegebenen Zeiträumen einfließen ohne den ganzen Wiederaufnahme tamtam durchlaufen zu müssen.

Und wenn es nicht besser wird kann der normale deprecation Prozess durchlaufen werden und irgendwann wird es halt das neue "ZFS" das eigentlich von gut sein soll, aber halt nicht im Kernel ist.

OpenSuse hat inzwischen bereits Konsequenzen gezogen.
https://www.linux-magazin.de/news/opens ... -bcachefs/
Sie liefern den Kernel zukünftig wohl ohne das Dateisystem aus und alle die es benutzen wollen müssen wohl auf ein DKMS warten welches das extern weiterentwickelte Dateisystem ausliefert.

Ich vermute mal das andere Distributionen den selben oder ähnliche Wege gehen werden. Weiss jemand schon was die Gentoo-Devs planen?

Zu 6.18 fliegt es komplett raus: https://www.linux-magazin.de/news/bcach ... s-zurueck/

misterjack wrote:Zu 6.18 fliegt es komplett raus: https://www.linux-magazin.de/news/bcach ... s-zurueck/

Ich finde es zwar schade das dieses Dateisystem endgültig aus dem Kernel fliegt aber besser so als zwei Versionen im Umlauf zu haben die in Zukunft zueinander inkompatibel sein können/werden.