(Welches) BSD auf dem Desktop?

Die Erkennung ist gemeint, die Stabilität ist in Ordnung.

Irgendwie scheint es, man sollte sich gut überlegen, welche Variante man wählt, >4GB mit fragwürdiger IOMMU, oder <<4GB.

Gefunden in openbsd.misc:

You have to edit a source file and recompile the kernel.
However, it won't work (to be precise, it will probably crash on boot, or
possibly afterwards) unless you have an IOMMU, and most Intel systems don't.
OpenBSD doesn't support the AGP/PCI-e GART as an IOMMU, and I'm not sure
if it supports VT-d platforms (which you probably aren't running anyway).
The only option here is AMD.​
 
Außerdem schlägt jede Art von Unstabilität/Datenverlust bei ZFS/HAMMER/etc riesen Wellen. Wenn bei einem Linux mal wieder jemand sein ext* zerschossen hat => "who cares?"

Naja, wenn eine S-Klasse einfach so auf der Autobahn anfängt zu brennen ist das schon 2-12 Meldungen wert. Wenn das mit einem Kia passiert, who cares? Kommt halt vor. (Und genau so hab ichs schon mal erlebt. War natürlich nicht mein Kia. Aber ich hab drin gesessen und mich gewundert. Jetzt würde ich mich nicht mehr wundern.)
 
Naja, wenn eine S-Klasse einfach so auf der Autobahn anfängt zu brennen ist das schon 2-12 Meldungen wert. Wenn das mit einem Kia passiert, who cares? Kommt halt vor. (Und genau so hab ichs schon mal erlebt. War natürlich nicht mein Kia. Aber ich hab drin gesessen und mich gewundert. Jetzt würde ich mich nicht mehr wundern.)

Manche Leute braten Eier auf dem Motorblock und wundern sich dann, dass irgendwas zu brennen anfängt...

Quasi analog: Ein Kollege von mir hatte sich bitterlich beklagt, dass sein damaliges Filesystem so furchtbar instabil sei. smartmontools zeigte mir bei seiner Maschine, dass die Lesefehler inzwischen weit in die Milliarden gingen, die seine Plattenelektronik alle per ECC wieder ausgebügelt hatte, oder besser gesagt, versucht hatte auszubügeln.

Es war wohl keine gute Idee gewesen, vier Platten an ein etwas schwächliches Netzteil zu hängen.

Moral: Die Leute bauen sich einen Haufen Schrott zusammen und wundern sich, wenn die Software darauf nicht dauerhaft stabil läuft. Das machen sogar Leute, die damit ihr Geld verdienen wollen. :zitter:
 
Also, da ich beruflich jede Menge FreeBSD-Systeme unter meiner Fuchtel habe, kann ich da in gewisser Weise aus Erfahrung sprechen. Allerdings nicht zu HAMMER, da wir hier ein reiner FreeBSD-Laden sind und es daher nicht einsetzen können. Wir haben allerdings von Kollegen übernommene Linux-Boxen im Einsatz und damit auch deren Dateisysteme:

1. UFS und UFS2 sind recht eindeutig die stabilsten und zuverlässigsten aller Dateisysteme hier. Das ist natürlich auch irgendwo ihrem sehr simplen Aufbau geschuldet. Wir hatten mit UFS schon wirklich jeden Mist, den man sich vorstellen kann, mehr als mal ein oder zwei Dateien verloren haben wir niemals. Und bisher konnte auch jedes Dateisystem wieder repariert werden, auch wenn dazu teilweise >5 fsck-Läufe notwenig waren... Im Einzelnen hatten wir:
- Über mehrere Wochen defekte S-ATA Kabel, der Kunde wunderte sich, wieso die Kiste immer abschmierte. Das Dateisystem war sehr defekt, Datenverlust trat nur auf wo eine Datei andere überschrieben hat, da die entsprechenden ATA-Kommandos zerdeppert wurden.
- gmirror-Wiederherstellung. Platte A synchronisiert auf B, sie liefen zuvor mehrere Tage asynchron. System schmiert dabei wieder ab, da Platte A defekt ist. Kollege ersetzt ohne nachzudenken Platte A, nun synchronisiert B auf A. In der Folge war der Mirror ca. zur Hälfte neu und zur Hälfte alt. Mehrere fsck-Läufe später war das Dateisystem wieder heil, alle nich synchronisierten Daten waren noch da.
Vielleicht versteht man jetzt, wieso ich nach wie vor ein großer Fan von UFS bin.

2. ZFS. Schwer dazu nun der Weisheit letzten Schluss zu ziehen, denn wir setzen es noch nicht sehr lange ein. Aber bisher hatten wir auch auf Systemen mit sehr hoher Last keinerlei Abstürze und wir hatten auch noch keine kaputten Pools und keinen Datenverlust. Dazu muss man auch sagen, dass viele der ZFS-Horrorgeschichten (mein Pool ist im Eimer, die Kiste schmiert ständig ab) größtenteils ihren Ursprung in Zeiten haben, wo einige Idioten es trotz groß sichtbaren "experimental"-Hinweis schon produktiv einsetzen mussten. Einen Nachteil hat ZFS allerdings. Als COW-Dateisystem fragmentiert es recht stark.

3. Linux-Dateisysteme. Mit Linux verbindet mich etwas Hass, da ich dem Ding diverse Nachtschichten zu verdanken habe. Das liegt nicht unbedingt am Kernel selbst, stattdessen an schnoddrigen Distributionen und unfähigen Admins, aber ich neige zu Verallgemeinerungen... Allgemein sind meine Erfahrungen mit den >30 Linuxdateisystemen sehr durchwachsen. Viele produktiv einsetzbare würden unter FreeBSD noch immer mindestens als "experimental" segeln, einige sicher sogar als "unsupported". Größere Erfahrungswerte habe ich mit:
- XFS. Kenne ich noch aus meiner Irix-Zeit. Dort hieß Crash immer gleich Backup holen. Das ist unter Linux wesentlich besser geworden, sicher auch durch Write Barriers. Allerdings stehe ich nach wie vor auf dem Standpunkt, dass XFS im Katastrophenfall unschön ist. Die Wahrscheinlichkeit, dass der B-Baum implodiert ist sicher noch immer ~10% und wenn es passiert, ist alles verloren. Dann hilft nur noch mkfs. Kann man einsetzen, ist sehr schnell, sollte aber tunlichst nur mit USV passieren.
- Ext3. Alle Ext sind UFS-Klone, die allerdings einiges an Magie einsparen. Ich habe Ext3 immer als grottenlahm erlebt, ist aber zugeben doch recht zuverlässig. Wenn wirklich mal alle Stricke reißen, kann man oft zumindest noch die Daten runterziehen.
- JFS. IMO von allen Linux-Dateisystemen der beste Kompromiss aus Stabilität und Geschwindigkeit. Hatte ich sehr wenig Ärger damit, hat sich als sehr Katastrophenresistent gezeigt. Ich frage mich, wieso es sich nie weiter durchgesetzt hat.
- btrfs. Ich bin da noch gespannt. Es wurde imo für ein so komplexes Dateisystem viel zu früh als stabil deklariert, sicher aus unter Druck der Entwickler und erster Nutzer wie Intel. Muss man mal sehen. Wenn ich meine Abneigung gegen streng baumbasierte Dateisysteme mal einen Moment vergesse, schaut es konzeptionell recht gut aus. Das einige Kollegen aber meinen es schon im großen Stil nutzen zu müssen, ist in meinen Augen idiotisch.
 
Wir hatten mit UFS schon wirklich jeden Mist, den man sich vorstellen kann, mehr als mal ein oder zwei Dateien verloren haben wir niemals. Und bisher konnte auch jedes Dateisystem wieder repariert werden, auch wenn dazu teilweise >5 fsck-Läufe notwenig waren...

Ca. 2003 hatte ich einen vergleichbaren Fall, auf einem damals aktuellen FreeBSD. Die Hardware war anscheinend vollkommen in Ordnung, aber einige Dateieinträge waren sichtbar angeschlagen, wenn auch die Daten selbst lesbar waren. Mit jedem fsck-Lauf wurden mehr und mehr inodes ausgehängt oder truncated, bis schließlich auf der Platte nichts mehr übrig war, was man hätte verwenden können. Das hinterließ bei mir den Eindruck, dass UFS vielleicht total in Ordnung ist, aber die fsck-Implementation wohl sehr fragwürdig. Die Crosslinks, die fsck behauptete, konnte ich manuell vor dem ersten Plattencheck bis auf 1,2 Fälle gar nicht nachvollziehen.

XFS. Kenne ich noch aus meiner Irix-Zeit. Dort hieß Crash immer gleich Backup holen.

XFS hat seinen schlechten Ruf hauptsächlich aus der Zeit, als Meta-Daten asynchron zu den Daten geschrieben wurden. Dadurch bekam man bei so gut wie jedem Crash eine Platte, auf der nichts mehr in Ordnung war. Das hat sich zwar geändert, aber niemand hat wohl groß Lust, das auszuprobieren.

JFS. IMO von allen Linux-Dateisystemen der beste Kompromiss aus Stabilität und Geschwindigkeit. Hatte ich sehr wenig Ärger damit, hat sich als sehr Katastrophenresistent gezeigt. Ich frage mich, wieso es sich nie weiter durchgesetzt hat.

Bei einem Benchmark von mir performte JFS sehr mittelmäßig - aber anscheinend völlig unvorhersagbar. Das zittrige Diagramm mit seinen Beulen war sehr originell - und bewies hauptsächlich, dass sich dieses Filesystem sehr gerne mit sich selbst beschäftigt, und wenn, dann auch gerne länger.

btrfs. Ich bin da noch gespannt.

Ja. Es gibt da auch noch andere Projekte - wie z.B. Next3. Die Euphorie, die Projekte wie Reiser4 wohl lange Zeit beflügelten, scheint komplett vergangen. Es gibt nur ganz wenig brauchbare Informationen...
 
Yanestra schrieb:
Ca. 2003 hatte ich einen vergleichbaren Fall, auf einem damals aktuellen FreeBSD. Die Hardware war anscheinend vollkommen in Ordnung, aber einige Dateieinträge waren sichtbar angeschlagen, wenn auch die Daten selbst lesbar waren. Mit jedem fsck-Lauf wurden mehr und mehr inodes ausgehängt oder truncated, bis schließlich auf der Platte nichts mehr übrig war, was man hätte verwenden können. Das hinterließ bei mir den Eindruck, dass UFS vielleicht total in Ordnung ist, aber die fsck-Implementation wohl sehr fragwürdig. Die Crosslinks, die fsck behauptete, konnte ich manuell vor dem ersten Plattencheck bis auf 1,2 Fälle gar nicht nachvollziehen.
Ja, das war die Frühzeit des UFS2 fsck. Ich hatte bis 8.0 sogar ein eigenes fsck in der Firma, was ein wenig aggressiver als offizielle war. Inzwischen sind solche Probleme aber behoben. Die aktuelle fsck Implementierung kommt mit viel weniger Speicher als damals aus, sie erkennt wesentlich mehr Defekte korrekt und kann - wenn wirklich alle Stricke reißen sollten - komplette Cylinder Groups ausradieren.

Yanestra schrieb:
XFS hat seinen schlechten Ruf hauptsächlich aus der Zeit, als Meta-Daten asynchron zu den Daten geschrieben wurden. Dadurch bekam man bei so gut wie jedem Crash eine Platte, auf der nichts mehr in Ordnung war. Das hat sich zwar geändert, aber niemand hat wohl groß Lust, das auszuprobieren.
Wie gesagt, ganz so glücklich bin ich damit nach wie vor nicht. Aber ich sage auch nicht, dass XFS generell problematisch wäre. Dafür habe ich zu wenig Kisten damit. Man kann das Linux-XFS auch kaum mehr mit dem Irix-XFS vergleichen. Die Implementierung scheint sich schon sehr geändert zu haben...

Yanestra schrieb:
Bei einem Benchmark von mir performte JFS sehr mittelmäßig - aber anscheinend völlig unvorhersagbar.
Okay, wirkliche Benchmarks habe ich damit nie gemacht.
 
Yanestra schrieb:
Betrifft das alle BSDs? (Ich blicke manchmal nicht wirklich durch, ob und welche Änderungen übernommen werden.)
Ich weiß es nicht. OpenBSD hat diese Änderungen sicher schon oder wird sie dann recht zeitnah bekommen. Im Moment geht es ja noch... Ansonsten divergieren die UFS2-Implementierungen im Moment mal wieder recht stark, weshalb es mit schnell mal Code übernehmen wohl vorerst mal wieder vorbei ist:
- FreeBSD bekommt mit 9.0 (ca. Mitte bis Ende 2011) "Journaled Softupdates". Das ist eine Erweiterung auf Softupdates, diese funktionieren weiterhin wie bisher, aber Löschoperationen werden in einem Journal gespeichert. Damit ist dann das im Moment zum Freigeben von fälschlich als belegt markierten Speicherplatz nach unsauberem Aushängen notwenige fsck nicht mehr nötig.
- NetBSD hat nun schon seit längerer Zeit Softupdates optional komplett gegen den Journal-Mechanismus WAPL ersetzt.
- OpenBSD scheint vorerst an reinen Softupdates festzuhalten.
- DragonFly hat UFS2 bekanntlich durch HAMMER abgelöst.
 
Die Lage scheint ja ein bißchen unübersichtlich zu sein.

Hat jemand zufällig Lust, eine kleine Zusammenfassung ("Unterschiede bei den BSDs") zusammen mit mir zu pflegen? Ich denke, das würde Sinn machen, und man könnte dokumentieren, welches BSD momentan wie weit ist und wohin es eigentlich will.
 
Zuletzt bearbeitet:
Das ist doch was komplett anderes (ein Blog)?

Ursprünglich war Kerneltrap etwas konziser und brachte bloß einschlägige ML-Kommentare nach dem Motto xyz hat seinen neuen Patch vorgestellt, mit dem das Feature abc jetzt plötzlich viel schneller/besser/schöner läuft usw.

Ich denke, das eine bedingt das andere. Eine Aussage wie "Openbsd finally got UFS2" allein ist nicht gerade exzellent ergiebig, wenn man nicht dazusagt, dass es auf einem anderen Framework aufsetzt...

Eine normale Liste artet so schnell in eine Fußnotenwüste aus, daher würde sich das Format eines Blogs doch schon anbieten...
 
Dann schlag mal ein detaillierteres Konzept vor, wie du dir das vorstellst.

Ich dachte an eine Reihe von Artikeln. Z.B. Thema UFS2: Wer unterstützt es? Wer plant es zu unterstützen? Worauf setzt es auf? Was unterscheidet jetzt A von B? Sind sie kompatibel, wo nicht? Welcher Code wird benutzt? Wer unterstützt Journaling/Softupdates usw. und was soll das bringen?

Interessant wäre auch, FreeBSD im Vergleich mit z.B. NetBSD zu betrachten, weil letzteres nur wenige Änderungen mitzunehmen scheint - welcher Code-Stand ist das eigentlich?

Ein Wiki würde sich dafür anbieten.

Das wäre dann sozusagen der Ist-Stand.

Und ein dazu passender Blog-Channel, der dazugehörige Aussagen in Mailinglisten bringt. Nur in Zusammenfassung, nachdem die eigentliche Diskussion gelaufen ist.

M.K.McKusick bastelt z.B. anscheinend fleißig an fsck_ffs herum - warum eigentlich? Was sind da die akutellen Änderungen?

Ich glaube, letzteres würde am meisten Arbeit machen und am ehesten liegenbleiben.
 
Die Schwierigkeit besteht denke ich auch auch darin die Vielzahl an Informationen (verschiedene Derivate und unterschiedliche Thematik) noch übersichtlich zu halten.
Da wäre dann sicher ein Leitfaden oder eine "Inhaltsangabe" noch ganz praktisch.

Aber das wird kompliziert einfach zu halten ;)
 
Zurück
Oben