Du verwendest einen veralteten Browser. Es ist möglich, dass diese oder andere Websites nicht korrekt angezeigt werden. Du solltest ein Upgrade durchführen oder einen alternativen Browser verwenden.
NewsLinux News der Woche: Radeon für Loongson, Mesa 23.4.0, Brennpunkt Dateisysteme
Außerdem hat die Zeit auch das System selbst überholt. Mit dem Wegfall von Reiser als Hauptkraft hinter der Entwicklung ist natürlich auch einiges an Ansporn hinter dem System verloren gegangen. Die damaligen Vorteile hat heute so gut wie jedes halbwegs aktuelle Dateisystem integriert oder noch einmal überdacht.
Schade dass der Heise Verlag dir Website insgesamt unattraktiv gemacht hat. Die ct als Magazin war (ist) auch ein herausragendes Pressewerk
Inhaltlich ist es gut, dass hier auch Mesa thematisiert wird. Der Blick “nur” auf den Kernel lässt sonst das ganze GNU an Linux aus. Die Verbesserung für Counter-Strike interessieren mich.
Also Wirtschaftspolitisch sind die Exportbeschränkungen für China ein Schuss ins eigene Knie. Nach 15 Jahren, von denen schon einige um sind, haben die komplett eigene Fertigung und Chipdesigns, und wir keinerlei Umsatz mehr.
Da stimme ich grundsätzlich zu, aber bcachefs wird ja afaik sowieso primär von Overstreet entwickelt - oder gab es da schon größere PRs von anderen? Und wenn der einzige Hauptentwickler und Maintainer eben permanent und unbelehrbar gegen die Regeln, Sitten und Gepflogenheiten verstößt, dann kann man das ja schon auch als "technischen" Grund ansehen, da diese Spielchen ja auch die Zeit der anderen Entwickler/Maintainer fressen...
Jenes. ReiserFS war schon lange im Kernel, aber es gibt kaum Nutzer, es findet keine Entwicklung statt.
Wahrscheinlich will sich niemand mit ReiserFS beschäftigen aufgrund des Mordes.
Reiser selbst erklaerte ReiserFS fuer fertig und seine Firma stellte die Entwicklung ein, weil fuer ihn Reiser4 der neue heisse Scheiss war, noch bevor er seine Frau ermordete. Ein paar Tage nach dem Mord und noch vor der Verhaftung gab es den Vorschlag, SUSE's Default-Filesystem von ReiserFS auf Ext3 umzustellen, und 2 Tage nach der Verhaftung entschied SUSE, das so zu tun. Angesichts der typischen Geschwindigkeit von Entscheidungsprozessen schaetze ich, dass der Grund dahinter war, dass die Entwicklung eingestellt worden war, dass die Verhaftung aber dafuer gesorgt hat, dass die Entscheidung beschleunigt und schneller bekanntgegeben wurde. Also fuer ein Dateisystem, an dem vor 2 Jahrzehnten die Entwicklung grossteils eingestellt wurde (ich lese, dass Bug Reports an ReiserFS mit "Use Reiser4" geschlossen wurden), hat sich ReiserFS lange gehalten.
Seh ich anders. Wer nicht in der lage ist, a) mit anderen zusammen zu arbeiten und b) sich an die etablierten Regeln und Vorgaben zu halten, muss halt gehen. Was bringt der Typ, wenn dafür 3 andere hinwerfen, weil sie keinen bock mehr auf seine Faxen haben? nichts.
Software im Team ist Teamwork und wer zwar technisch was kann aber kein Teamwork der ist auch nichts Wert, wie gesagt kann er ja alleine sein Ding machen, das steht ihm frei.
Niemand aber wirklich niemand kann jemanden im Team gebrauchen der nicht in der Lage ist sich zu integrieren
Danke für die Zusammenfassung. Ist doch einiges drin, was ich nicht mitbekam. Ich sehe das so wie Krik und bcachefs sollte einfach als Modul bleiben und nicht aufgenommen werden. Wenn sowohl der Programmiere als auch das Dateisystem selber reifer sind, kann man über eine Aufnahme in den Kernel denken, vorher aber nicht. Und danke für die Verlinkung der letzten News. Die ist bei mir komplett vorbei gegangen.
Man kann ja BCacheFS bzw den Entwickler konkret kritisieren. Aber das ändert nichts daran dass ein anderes Dateisystem doch schon nützlich sein könnte.
Ex4 und XFS ist schnell hat aber keine Prüfungen bzw Daten Integrität auf normalen Daten, ich meine hier also nicht die Metadaten. Auch haben sie keine Snapshot-Funktion. Die beiden Dateisysteme die das haben, also ZFS und das andere schon besser in Linux integrierte System (btfrs) sind deutlich langsamer. Entsprechend fehlt da ein Betriebssystem was wie bcachefs das Ziel hat eben schneller zu sein aber eben mehr Funktion als XFS und ext4 zu haben. Ich fände ja schon einfach ein Datrisystem was diese Prüfungen bzw integritätsfunktion auf nomalem Daten, hat aber nicht unbedingt Snapshots unterstützt super, wenn es das geben würde (schneller natürlich als ZFS und btfrs). Beides und zumindest etwas schneller als die beiden existenten wäre auch gut (Bcachefs).
und davon, dass ext4 (und bcacheFS) offenbar einen Geschwindigkeitsvorteil zu zfs/btrfs haben. wie groß ist denn der Performance-Nachteil von letzteren?!
Da gibt es ein fettes "es kommt darauf an". BcacheFS hat tendenziell einen Vorteil was die Struktur angeht, je nach aktiviertem Feature wird dieser Vorteil aber nahezu nichtig. Abseits davon hat BTRFS leider noch arg Performanceprobleme mit aktiven QuotaGroups in Verbindung mit Snapshots.
Dort wo I/O-Durchsatz gebraucht wird, muss man sich mit den Dateisystemen entsprechend beschäftigen (oder gleich nativ auf den Datenträger drauf) und abseits davon ist es eigentlich immer unproblematisch.
BrollyLSSJ schrieb:
Ich sehe das so wie Krik und bcachefs sollte einfach als Modul bleiben und nicht aufgenommen werden.
Dateisystem als externes Moduls ist halt wirklich schmerzhaft. Den Aufwand das Modul mit den je aktuellen Kernelversionen kompatibel zu halten frisst zu viel Ressourcen. Bei OpenZFS mag es noch gehen, weil mehrere Entwickler·innen daran arbeiten. Bei einem einzelnem Entwickler, der tendenziell Mitstreiter vertreibt wird es aber eher nichts.
Zudem BcacheFS ja Jahre als Modul hinter sich hatte und die Entwicklungen die jetzt in den Kernel fließen weit weg sind irgendwie ausgereift zu sein.
Die warscheinlichste Lösung wäre mmn BcacheFS klonen und einen neuen Maintainer zu suchen. das eigentliche ziel der kernelaufnahme war ja, das der Entwickler weitere Supporter gewinnt - das ist jedenfalls gescheitert.
@netzgestaltung
Klonen ist ja nicht notwendig, der Code ist ja zwangsweise unter GPLv2 eingebracht und funktionelle Duplikate werden im Regelfall nicht in den Kernel übernommen.
Falls Kent sich nicht etwas verbessert, wird er den Maintainerstatus für BcacheFS verlieren und dann wird sich Zeigen ob es irgendwer übernehmen will. Da habe ich aber fast Zweifel, bei BTRFS sehen wir ja seit einer Dekade, wie gering das Interesse ist da mal gescheit Ressourcen drauf zu werfen.
@Piktogramm Kennst du ein Dateisystem, dass Datenintegriät/Prüfusummen hat (nicht nur Metadaten, sondern auch auf normalen Inhalten), aber keine Snapshots und dafür schnell ist?
@DoS007
BTRFS und ZFS kannst du auch ohne Snapshots zu nutzen nehmen. BTRFS ist meist schnell genug, ZFS dennoch schneller und mit vertretbarem Aufwand nutzbar.
Die klassischen Dateisysteme, die über die letzten Dekaden gereift sind, tun es immer noch, sofern man nicht CoW-exklusive Funktionen benötigt.
Die Geschwindigkeit spricht für sich.
@Krik XFS, Ex4 machen das leider nicht auf den Inhaltsdaten (mit der Intergrität). Das ist gerade der Punkt, den ich meinte, ich kenne da keines.
@Piktogramm BTRFS ist schon deutlich langsamer als XFS oder Ext4, siehe auch den von @Krik verlinkten benchmark. Auch ZFS kommt an die Geschwindigkeit leider nicht ran (und braucht on top auch noch einiges an RAM, 1 GB Ram pro 1TB).
@DoS007
Wenn du COW und Checksumming wird immer Performance kosten und ohne COW sehe ich wenig Sinn Checksummen einzusetzen (wenig, nicht Garkeinen).
Die Benchmarks von Phoronix, solang BcacheFS kein Scrubing implementiert hat kann es schnell sein und Checksummen berechnen wie es will. Auch die Geschwindigkeit, dass letztemal als ich nachgeschaut habe war Defragmentierung auch noch kein Ding (ebenso wie Balancing)[1]. Insofern, das Dateisystem ist "experimental" zurecht und die Performance ist bisher auch nur für nagelneue Partitionen gezeigt und eben nicht für gut genutzten Speicher.
Das ZFS so viel Speicher benötigt ist eine Sage aus Unverständnis heraus. Wer ZFS, BTRFS und potentiell BcacheFS mit Deduplication betreiben will braucht viel Arbeitsspeicher. Der Standardwert für Dedup ist aber eigentlich bei allen Dateisstemen "false". Ohne Dedup ist der Mehrbedarf an Speicher um die Dateisystemtabelle und Metadaten von COW-Dateisystemen eher gering.
[1]Und auch wenn es mit SSDs weniger schlimm ist, wenn man die Vorteile von COW/Snapshots mitnimmt, bekommt man auch den Durchsatz von SSDs deutlich reduziert.
@Piktogramm Es geht darum, die Sicherheit der Daten zu gewährleisten, die akutell auf der Platte sind (Datenintegrität ohne COW), z.B. Schutz vor Bitflips bei lang ausgeschalteten SSDs usw. und generell. Daher schon wünschenstwert und wenn ohne COW Performancegewinn vorhanen ist - super. Kenne aber kein solches Dateisystem.
Performance ist bisher auch nur für nagelneue Partitionen gezeigt und eben nicht für gut genutzten Speicher.
Ah ok, wusste nicht, dass die Depulizierung Hauptverantwortlich für die RAM-Belastung ist bei ZFS.
Zu [1]: Also weniger TBW bei Defragmentierung auf SSDs meinst du?
Nehme an du nutzt ZFS? (Würde das nur bei einer Distribution verwenden, die das automatisch mitbringt und sich nicht vor den Lizenzrechten fürchtet wie der Linux-Kernel)
Brauche ich die Features von Btrfs als privater Heimanwender / Gamer?
So wie ich es verstanden habe, setzen die meisten Leute nur wegen der Snapshot- und Self-Healing-Features auf Btrfs. Ich persönlich finde, dass das zu schwache Argumente sind, da man im Alltagsgebrauch bis zu 75% Geschwindigkeitseinbruch gegenüber Ext4 und Xfs hat (siehe Phoronix). Und das nur, damit das Backup in ein paar Sekunden statt in einer Stunde im Hintergrund durchläuft? Und damit Daten repariert werden, die ohnehin im Backup liegen? Muss man für sich abwägen. Ich weiß, worauf ich meine Prioritäten lege.
Das Steam Deck nutzt Btrfs für / (5 GB) und Ext4 für /var (256 MB) und /home (Rest von der Platte)
@Krik Du hast die Datenintegrität vergessen, das ist für mich mit das größte Argument für Btrfs und ZFS. Bei XFS und Ext4 werden nur Veränderungen der Metadaten bemerkt, wenn Inhaltsdaten sich irgendwie verändern: Pech gehabt und gar nicht gemerkt, dass Backup-Wiederherstellung wichtig gewesen wäre.
