Von FreeBSD zu OpenBSD – softdep-Entfernung: Wirklich ein Problem?

[pit234a]

Systeme auf denen ich btrfs einsetze: 1
Systeme, auf denen ich heute Datenverlust nach Stromausfall hatte: 1

Erwartungshaltung.

Also durchaus nicht als Antwort oder gar kritische Anmerkung gedacht, sondern nur durch den zitierten Beitrag in diese Richtung geschubst, denke ich eben an folgendes Szenario:
Auf einen USB-Stick installiere ich irgendein System auf irgendeinem Dateisystem und starte dann von diesem Stick.
Nun ziehe ich im laufenden Betrieb den Stick mal ab (aka Stromausfall), warte einige Sekunden, stecke den Stick wieder und erwarte, dass alles wieder gut ist und das System problemlos weiter läuft.
Tut es das, bin ich happy und nenne das Dateisystem gut und robust?

Also, ich erwarte das nicht und ich erwarte auch nicht von einem Dateisystem, so zu funktionieren, dass es Daten über einen plötzlichen Störfall hinaus lückenlos bewahrt. Das ist sicher eine schöne Vorstellung, aber die Realisierung lückenloser Daten-Koherenz liegt doch auf einem anderen Layer, als auf Dateisystem-Ebene.

@Yamagi hat ja schön beschrieben, wie abhängig man hierbei auch von "lügender HW" ist und den einen Unterschied, zwischen synchron und eben nicht synchron Daten schreiben deutlich gemacht. Manchmal will ich aber eben synchron Daten übertragen! Das hat dann einen guten Grund. Das bedeutet aber nicht, dass ich deshalb nun unbedingt ein Dateisystem haben möchte, das nur synchron kann.
Ganz im Gegenteil.
Ich unterscheide hier sehr zwischen laufendem System und dessen Anforderungen und meinen Wünschen für einen Datenspeicher und eventuelle Datenübertragung zu anderen Speichern.

Aber: macht das ein typischer Microsoft-Nutzer?
Muss das ein typischer OpenBSD-Nutzer berücksichtigen?
Oder ein FreeBSD-Nutzer?


Also, ich denke, dass man einfach mal das nutzen sollte, was das System per Default anbietet und dann weiter sehen.
Die Frage nach Dateisystemen und was sie so können ist sicher interessant, aber nicht entscheidend für die Wahl eines Systems. Also, davon abgesehen, dass ich persönlich nicht mehr hinter ZFS zurück will.

Aber, wenn ich nun irgendeine Linux-Distro mal ansehen und probieren möchte, dann interessiert es mich doch nicht in erster Linie, welches Dateisystem die benutzt und ob da Journals gemacht werden.

Wenn ich mal eben OpenBSD nutzen möchte und es kennen lernen will, dann... man entschuldige mich und meine Ausdrucksweise, dann scheiße ich doch auf die Frage nach softdep oder nicht im Dateisystem, sondern nehme es eben, wie es angeboten wird.

Die Frage nach Dateisystemen und was diese können, ist für den Betrieb eines Systems absolut untergeordnet und es wird wohl niemand heutzutage noch einen File-Server bauen wollen und Daten in Menge hosten, wenn er nicht außer FFS, UFS, NTFS, ext2 ... noch was anderes hat.

 

[Andy_m4]

Schwieriger war so ein passiv gekühltes ASRock Board das ich als "Homeserver" betrieben hatte. Das war son Celeron-Ding, mäßig vom Hersteller zusammengedöngelt und da hatte ich mehrfach verschiedenes mit.

Was so passiv gekühlte Boards im ITX-Format angeht, waren ja mal diese Gemini-Lake-CPUs sehr beliebt. ASRock hat da natürlich Boards gebaut, aber ich hab eines von Biostar und das läuft (allerdings mit FreeBSD) zufriedenstellend.
Jedenfalls vermute ich mal, das das bei Dir so etwas Ähnliches war.

 

[CommanderZed]

Was so passiv gekühlte Boards im ITX-Format angeht, waren ja mal diese Gemini-Lake-CPUs sehr beliebt. ASRock hat da natürlich Boards gebaut, aber ich hab eines von Biostar und das läuft (allerdings mit FreeBSD) zufriedenstellend.
Jedenfalls vermute ich mal, das das bei Dir so etwas Ähnliches war.

Ja, ich meine, ich kann die Tage mal schauen, der läuft mit Archlinux nämlich sogar bei mir noch als ZFS-Backup-Ziel, aber halt nicht permanent (aber stabil).
(Der steht meist abgeschaltet in meiner Garage als "Gesamtbackup" mit 3 alten SATA-HDDs.
Alle paar Wochen hol ich den dann hoch zum komplett Backup des ZFS vom aktuellen "Homeserver", zusätzlich hab ich noch externe Festplatten als Backupziel die ich auch teilw. extern im wechsel komplett extern einlager, aber die sind inzwischen ne Idee zu klein fürs Gesamtbackup weshalb ich da einige unwichtige Sachen weglasse - das ist für meinen Privatgebrauch finde ich sophisticated genug)

Was ich gestern vergessen habe zu linux / default-filesystem: Bei den meisten Linuxdistries lässt sich das mit einen oder zwei Clicks während der installation ja auch ändern auf eine meist recht elaborierte Auswahl, da sollte für jeden was dabei zu sein.
Ich selbst verwende ja inzwischen meist Archlinux wo man während der "Installation" da die freie Wahl hat und auch keine direkte "Vorgabe". Mit ein paar größeren Klimmzügen kann man meine ich sogar auf ZFS als root installieren (Hab ich aber selbst nicht vertestet).

 

[Andy_m4]

eine meist recht elaborierte Auswahl

Wenn wir mal ehrlich sind: Mehr als tarfs braucht kein Mensch. Einfach direkt aufs Blockdevice schreiben. Fertig :-)

Mit ein paar größeren Klimmzügen kann man meine ich sogar auf ZFS als root installieren

Ergänzung:
Beschreibungen dazu, wie man das auf unterschiedlichen Linux-Distributionen hinkriegt, findet sich ja auch in der offiziellen OpenZFS-Doku:

Getting Started — OpenZFS documentation

openzfs.github.io

 

[cabriofahrer]

Ich habe es leider noch nicht geschafft, die vielen interessanten Beitäge zum Thema zu lesen. Ich hoffe, es stört nicht, wenn ich hier eine kleine Frage einwerfe, die mir in den Sinn kommt: Was kann man denn nach dem all hier Gesagtem zur Tauglichkeit von NetBSD als ServerOS sagen? War es z.B. nicht auch so, dass NetBSD schon vor FreeBSD Support für Multicore-CPU's hatte?

 

[Andy_m4]

Support für Multicore-CPU's hatte?

Meinst Du so was wie SMP-Support?
(man muss dazu sagen, das ist auch so ein bisschen ein fließender Prozess in der Art wie gut / performant das funktioniert)

FreeBSD 3.0 Release Notes:

The SMP (Symmetric MultiProcessing) branch has been merged. The kernel is mostly non-reentrant as yet, but work is under way.

NetBSD 2.0 Anouncement:

The addition of a native threads implementation for all platforms and symmetric multiprocessing (SMP) on i386 and other popular platforms were long-standing goals for NetBSD 2.0. Both of these goals have now been met—SMP support has been added for i386, SPARC, and PowerPC, the SMP support on Alpha and VAX has been improved, and the new port to the 64-bit AMD/Opteron also supports SMP.

 

[CommanderZed]

Ich habe es leider noch nicht geschafft, die vielen interessanten Beitäge zum Thema zu lesen. Ich hoffe, es stört nicht, wenn ich hier eine kleine Frage einwerfe, die mir in den Sinn kommt: Was kann man denn nach dem all hier Gesagtem zur Tauglichkeit von NetBSD als ServerOS sagen? War es z.B. nicht auch so, dass NetBSD schon vor FreeBSD Support für Multicore-CPU's hatte?

Bevor das abgleitet, wir unterhalten uns hier im Kern vor allem um Dateisysteme, etwas weiter noch im konkreten zusammenhang mit Abstürzen bei OpenBSD und OpenBSD als ServerOS aber auch sehr stark auf den Fokus "FFS und Probleme dadurch"
Nicht so sehr allgemein über "Tauglichkeit von xyz als Server OS", das ist auch nen gutes Thema aber es wäre lieb wenn du dafür einen separates Thema aufmachst, sonst wird das schnell unübersichtlich.
Gib mir einfach einen Wink wenn ich deinen und @Andy_m4 Posts zu dem Thema rausziehen soll, bitte mit aussagekräftigen Titel dann.

 

[cabriofahrer]

Bevor das abgleitet, wir unterhalten uns hier im Kern vor allem um Dateisysteme, etwas weiter noch im konkreten zusammenhang mit Abstürzen bei OpenBSD und OpenBSD als ServerOS aber auch sehr stark auf den Fokus "FFS und Probleme dadurch"

So hatte ich das auch verstanden. Ich war aber der Meinung, dass es sich vielleicht nicht lohnen würde, unter diesem speziellen Aspekt einen neuen Thread aufzumachen, sondern vielleicht kurz hier zu antworten, was man vielleicht dazu im Bezug auf NetBSD sagen könnte. Z.B. hat NetBSD ja auch FFS, wenn ich das richtig sehe. Stellt sich hier z.B. dann das gleiche Problem bei Stromausfall wie bei OpenBSD?

 

[Andy_m4]

Ich war aber der Meinung, dass es sich vielleicht nicht lohnen würde, unter diesem speziellen Aspekt einen neuen Thread aufzumachen, sondern vielleicht kurz hier zu antworten

Da Threads nichts extra kosten, ist es wahrscheinlich schlauer im Zweifel lieber einen neuen Thread aufzumachen, anstatt zu viele Themen in einen (damit ja auch letztlich sehr langen und dadurch unübersichtlichen) Thread zu packen.

Stellt sich hier z.B. dann das gleiche Problem bei Stromausfall wie bei OpenBSD?

Zumindest hat man die Möglichkeit in der /etc/rc.conf in fsck_flags -y zu setzen. Das erlaubt beim Boot-up fsck ein wenig "nachdrücklicher" zu sein als das normale fsck_ffs -p (siehe fsck_ffs(8)).

 

[CommanderZed]

So hatte ich das auch verstanden. Ich war aber der Meinung, dass es sich vielleicht nicht lohnen würde, unter diesem speziellen Aspekt einen neuen Thread aufzumachen, sondern vielleicht kurz hier zu antworten, was man vielleicht dazu im Bezug auf NetBSD sagen könnte. Z.B. hat NetBSD ja auch FFS, wenn ich das richtig sehe. Stellt sich hier z.B. dann das gleiche Problem bei Stromausfall wie bei OpenBSD?

Zum SMP: Linux 1996, FreeBSD 1998, OpenBSD und NetBSD 2004, ist ziemlich leicht zu googeln

Ich vermute das NetBSD das gleiche FFS-Problem hat wie OpenBSD, da ich kein NetBSD verwende kann ich nicht sagen ob der fsck besser unbeaufsichtigt durchläuft, vermute dank @Andy_m4 evtl. - das ist aber nur ein kleiner part des Problems. Mir fehlt auch die Erfahrung mit sonstigen abstürzen mangels NetBSD erfahrung, was ich so vom hörensagen kenne ist das die sich da nicht so viel tun.

Was das beste Server OS ist, ist son bisschen zu fragen wie "was ist denn das beste Fahrzeug" - teilweise sogar fast wie "was ist denn das leckerste Essen"

Es hängt stark davon ab was man macht, was wichtig ist, worauf ich wert lege, was die Anforderungen sind aber halt auch ein gutes stück weit "persönlicher Geschmack"

 

[Yamagi]

Alle BSDs nutzen FFS / UFS. Es ist das gleiche Dateisystem, was zwischen den BSDs über die Jahre allerdings etwas auseinandergelaufen und daher nicht mehr wirklich kompatibel ist. FreeBSD nennt es UFS, NetBSD und OpenBSD FFS. Das kommt daher, dass es von 4BSD einfach FFS hieß und mit 4BSD in zwei Layer zerlegt wurde. UFS ist der obere Layer, FFS der untere Layer. Es gibt zwar Argumente gegen UFS / FFS, vor allem im Vegrleich mit moderneren Dateisystemen, aber trotzdem: UFS / FFS ist ein sehr robustes, in Sachen CPU- und RAM-Bedarf äußerst effizientes, wenn asynchron gemountet oder mit Softupdates kombiniert sehr schnelles und auch mit extrem langsamen Speichermedien gut klarkommendes Dateisystem.

Es ist möglich ein UFS / FFS kaputt zu bekommen. Man kann alles irgendwie kaputt kriegen. Aber ein UFS / FFS wirklich irreparabel zu zerlegen ist wirklich schwer. Ich hab mal ein UFS2 unter FreeBSD aus äußerster Dummheit zu 50% per dd mit einer älteren Version von sich selbst überschrieben. fsck_ffs hat es wieder hingebogen. Wenn es wirklich kaputt geht, ist nicht selten lügende oder kaputte Hardware im Spiel. Auch hochwertige Hardware kann lügen. FreeBSD hat wahlweise Softupdates oder gjournal zur Konsistenzsicherung, NetBSD hat WAPBL und OpenBSD hat nichts. Daher muss man unter OpenBSD synchron mounten, was langsam ist - was aber nicht unbedingt sein muss - und recht allergisch auf lügende, sowie fragwürdige Hardware reagiert. Zumindest allergischer als FreeBSD mit Softupdates.

Nachtrag: Bei nochmal lesen klingt "und OpenBSD hat nichts" negativ. Das war nicht so gemeint.

 

[cabriofahrer]

Was das beste Server OS ist, ist son bisschen zu fragen wie "was ist denn das beste Fahrzeug" - teilweise sogar fast wie "was ist denn das leckerste Essen

Das war auch nicht meine Frage, abgesehen davon wäre es rein subjektiv für mich sowieso FreeBSD, was ich durch einige Beiträge hier auch teilweise bestätigt sehe.
Also ich denke, @Yamagi hat meine Frage zum Teil ganz gut und schnell beantworten können. Vor allem eine Aussage wie

FreeBSD hat wahlweise Softupdates oder gjournal zur Konsistenzsicherung, NetBSD hat WAPBL und OpenBSD hat nichts.

sagt ja auch schon etwas aus. Mir ist nur nicht ganz klar, was mit "lügender Hardware" gemeint ist?

 

[Yamagi]

Mir ist nur nicht ganz klar, was mit "lügender Hardware" gemeint ist?

Die Software fordert die Hardware auf, alle Daten, die noch im Flug sind dauerhaft auf die Festplatte zu schreiben. Die Hardware antwortet "Klar, hab ich gemacht" aber das ist eine Lüge. In Wirklichkeit hält sie die Daten weiter nur im Cache. Crasht dann das System oder der Strom fällt aus, sind die Daten aus den Caches weg. Da das Dateisystem aber davon ausging, dass sie dauerhaft geschrieben wurden, ist es anschließend kaputt.

 

[cabriofahrer]

Die Software fordert die Hardware auf, alle Daten, die noch im Flug sind dauerhaft auf die Festplatte zu schreiben. Die Hardware antwortet "Klar, hab ich gemacht" aber das ist eine Lüge. In Wirklichkeit hält sie die Daten weiter nur im Cache. Crasht dann das System oder der Strom fällt aus, sind die Daten aus den Caches weg. Da das Dateisystem aber davon ausging, dass sie dauerhaft geschrieben wurden, ist es anschließend kaputt.

Ist die "lügende Hardware" nur die Festplatte? Und gibt es einen Weg zu überprüfen, ob meine Hardware lügt oder nicht? Und: Ich glaube, ich hatte damals schon bei meinem UFS die Softupdates deaktiviert, weil das Problem in irgendeinem anderen Thread auftauchte, wenn auch anders beschrieben. Einzige Konsequenz ist, dass wenn in dem seltenen Fall, dass der PC fehlerhaft runtergefahren ist, fsck ziemlich lange braucht, um durchzulaufen. Im schlimmsten fall reicht das automatische fsck nicht und ich lande in der Shell und werde aufgefordert, fsck manuell durchzuführen. Ein fsck -y reicht dann und alles ist wieder gut. Dauert halt nur eine Weile.

 

[medV2]

Ist die "lügende Hardware" nur die Festplatte? Und gibt es einen Weg zu überprüfen, ob meine Hardware lügt oder nicht? Und: Ich glaube, ich hatte damals schon bei meinem UFS die Softupdates deaktiviert, weil das Problem in irgendeinem anderen Thread auftauchte, wenn auch anders beschrieben. Einzige Konsequenz ist, dass wenn in dem seltenen Fall, dass der PC fehlerhaft runtergefahren ist, fsck ziemlich lange braucht, um durchzulaufen. Im schlimmsten fall reicht das automatische fsck nicht und ich lande in der Shell und werde aufgefordert, fsck manuell durchzuführen. Ein fsck -y reicht dann und alles ist wieder gut. Dauert halt nur eine Weile.

Die Festplatte ist der übliche Verdächtige, da es billige Platten gibt, die aber "schnell" wirken wollen, und somit "ich hab schon alles geschrieben" gemeldet wird, obwohl die Daten teilweise noch im Cache sind. Damit es für den Konsument "schnell" aussieht. Wie schon beschrieben, bei teureren oder allgemein Businessprodukten hast du das Problem auch weniger. Der Raidcontroller kann jetzt natürlich auch lügen, aus selbigen Gründen. Da HW Raidcontroller aber sowieso eher ne Businesshardware sind, ist es da weniger der Fall.

Was den zweiten Teil deiner Frage betrifft: Mit SoftUpdates ist die Chance, dass im Fall des Falles etwas kaputt geht, halt dennoch geringer. Auch wenn man auch ohne das System oft noch mit fsck retten kann. Ich glaube Journaling UND SU hat sich nicht gut vertragen soweit ich mich erinnere.

 

[Yamagi]

Ich glaube Journaling UND SU hat sich nicht gut vertragen soweit ich mich erinnere.

Journaled Softupdates, kurz SU+J, waren am Anfang recht wackelig, wenn die Hardware nicht zu 110% korrekt funktionierte. Und sie spielten schlecht mit Snapshots zusammen. Ich und ein paar andere interessierte Personen sowie Organisationen haben dann insgesamt 50.000 Dollar gesammelt und Kirk McKusick so ermöglicht ich meine drei Monate Vollzeit daran zu arbeiten. Klingt viel, aber Berkeley ist ein teures Pflaster. Seitdem funktionieren sie unauffällig.

Ob SU+J nun eine gute Idee war und man nicht ganz in Richtung Journaling wie WAPBL hätte gehen sollen, ist eine andere Frage. Letztendlich ist es eine technisch sehr aufwändige Lösung für ein Randproblem: Softupdates halten das Dateisystem immer konsistent und es braucht nach einem Crash an sich kein fsck. Angebrachtes Misstrauen gegenüber der Hardware mal ausgenommen. Allerdings kann es passieren, dass eine Datei zwar gelöscht wurde, ihr Speicher aber noch nicht freigegeben. Das Dateisystem leckt in dem Fall sozusagen Speicher, das fsck räumt diesen wieder frei. SU+J schreibt Löschoperationen erst in ein Journal. Nach dem Neustart kann fsck das Journal durchgehen und schauen, ob der Speicher aller gelöschter Dateien vollständig freigegeben wurde. Damit verkürzt sich die fsck-Zeit um Faktoren.

Dann gibt es noch gjournal. Das implementiert Journaling in GEOM, also unter dem Dateisystem. Das Dateisystem muss lediglich kommunizieren, was ins Journal geschrieben wird. Im großen Bild ist das recht elegant, da man keine Anpassungen am VFS braucht und das sowieso vorhandene Metadaten-Filtering von Softupdates weiter verwenden kann. Ich habe das allerdings nie verwendet, weil es einige eklige Nebenwirkungen hat. Vor allem bricht es die Semantik von fsync(), was ein Problem sein kann, aber nicht muss.

 

[Andy_m4]

die aber "schnell" wirken wollen, und somit "ich hab schon alles geschrieben" gemeldet wird

Ja. Das ist echt schlimm.
Leicht Offtopic: Mir ist auch nicht klar, warum das nicht als Betrug gilt und überhaupt so verkauft werden darf.

 

[midnight]

Leicht Offtopic: Mir ist auch nicht klar, warum das nicht als Betrug gilt und überhaupt so verkauft werden darf.

Ist bei den Prozessorherstellern auch nicht anders. Hier fuehrt der Prozessor manche Befehle spekulativ aus, um eine hohe Effizienz zu erzielen. Natuerlich zulasten der Sicherheit. Spectre ist ein promitentes Beispiel.

 

[Andy_m4]

Spectre ist ein promitentes Beispiel.

Ja. Aber hier hatte es zumindest Folgen und da mussten die mit Updates gegensteuern.

 

[Azazyel]

Zu OpenBSD, ich hab hier auf den Mailinglisten, auch teilw. von Entwicklern gelesen, das man eigentlich kein anderes Filesystem braucht, weil das System angenehm einfach ist und sehr gut seinen job macht, und wenn man andere Erfahrungen hat halt einfach bessere Hardware und umstände braucht.

Selbst eine USV kann ausfallen. Das würde ich schon noch als Auslegungsstörfall sehen.

Mangels Problembewusstsein bei einigen und eine gewisse Ablehnung von vorsichtigen Rufen nach einem besseren Filesystemen, halte ich es für unwahrscheinlich das da demnächst etwas kommt.

Damit rechne ich auch nicht. Ich kann die OpenBSD-Entwickler und die Ursachen für die Abwesenheit eines guten Dateisystems voll nachvollziehen.

Leider kann man Spenden an OpenBSD in Deutschland nicht von der Steuer absetzen.

Das finde ich schon länger schade, da man sonst imho doch pragmatischer in dem Team ist, nehm ich aber so hin und bedenke es bei meinen Entscheidungen entsprechend, ähnlich wie @Azazyel.

Ich frage mich, wieviele Anwender der eh schon kleinen OpenBSD-Community das kostet.

Bei den meisten Wald-und-Wiesen-Linuxsystemen nutze ich privat und beruflich seit langer Zeit, dtl. länger als 10 Jahren, ext4, und auch bei sehr viel mehr Systemen als ich OpenBSD Systemen hatte, und ich kann mich an kein einziges mal erinnern wo ich da solche Probleme hatte.

Mit ext4 (spätestens mit data=journal) kann ich mich auch an keine Probleme erinnern.

Das ist imho schon nen ganz schöner Unterschied zu FFS unter OpenBSD in realen Anwendungen.

Nach dem Ausbau von Soft Dependencies hat man jetzt halt den Stand von ext2 erreicht.

Ich wollte im privaten Rahmen für ein kleines Projekt jetzt mal ein btfrs probieren, das scheint ja nun auch etwas abgehangen zu sein und dürfte für den Zweck ganz nett sein und ich verwende seit 1,5 Jahren privat produktiv auch ZFS (unter Linux), das ist schon wirklich, sobald man etwas mehr möchte, schon ziemlich cool.

Sowohl ZFS als auch btrfs (abgesehen vom bekannt kaputten RAID5/6-Modus) sind inzwischen auch abgehangen genug.

Für mich kommen Stand heute privat wie beruflich nur noch vier Dateisysteme (Cluster-Dateisysteme lasse ich mal außen vor) in Betracht:

• ZFS und btrfs aufgrund von CoW und Prüfsummen (für Daten und Metadaten)
• xfs und ext4 aufgrund von Journaling plus Prüfsummen (nur für Metadaten)

Bestimmt habe ich jetzt noch einen Kandidaten vergessen...

Ja. Das ist echt schlimm.
Leicht Offtopic: Mir ist auch nicht klar, warum das nicht als Betrug gilt und überhaupt so verkauft werden darf.

Die Hersteller sind hier in einer Zwickmühle. Machen sie es ordentlich, kacken sie bei allen Benchmarks gnadenlos gegenüber der Konkurrenz mit unsauberem Caching ab.

 

[CommanderZed]

Selbst eine USV kann ausfallen. Das würde ich schon noch als Auslegungsstörfall sehen.

Etwas OT: Ich hatte beruflich (Jaja Windows-Server und kleiner Scope ) fast genauso oft USV-Störfälle (So klein bis mittelgroße 20KVA Anlagen) wie Stromausfälle, so das ich dazu übergangen bin bei redundanten Netzteilen ein beinchen ins normalnetz (+Netzfilter usw davor) und ein Beinchen ans USV Netz zu hängen, dann ist es zumindest nicht so dramatisch wenn ne USV einfach von jetzt auf gleich und ohne Warnung einfach komplett ausfällt.
(Ich weiß das es da unterschiedliche Philosophien gibt)

 

[cabriofahrer]

Da hier mehrfach btrfs erwähnt wird, wollte ich mal kurz in den Raum stellen: Ich hatte vor einigen Jahren mal ein Video mit einem Kernel-Entwickler von FreeBSD auf Youtube gesehen und der nannte btfrs als Negativbeispiel, dem er niemals seine Daten anvertrauen würde. Inwieweit das gerechtfertigt oder übertrieben ist, kann ich natürlich nicht sagen, aber ich denke, die Meinung eines FreeBSD Kernel-Entwicklers ist sicherlich keine unwichtige Meinung.

Ob SU+J nun eine gute Idee war und man nicht ganz in Richtung Journaling wie WAPBL hätte gehen sollen

WAPBL scheint ja eine gute Sache zu sein. Demnach sehe ich letztendlich meine Zwischenfrage zu NetBSD und seiner Geeignetheit unter dem hier diskutierten Aspekt, Stromausfall und möglicher Datenverlust mit FFS unter OpenBSD, eigentlich beantwortet. Also abgesehen von FreeBSD, würde ich persönlich doch dann NetBSD den Vorzug für den Serverbetrieb geben.

 

[Andy_m4]

Machen sie es ordentlich, kacken sie bei allen Benchmarks gnadenlos gegenüber der Konkurrenz mit unsauberem Caching ab.

Das stimmt zwar. Aber genau deshalb hab ich ja die Vokabel "Betrug" benutzt. Also als regulatorischen Fall und eben nicht alleiniges verlassen auf fair game.

Stromausfall und möglicher Datenverlust mit FFS

Unabhängig von Deiner Entscheidung:
Wie oft rechnest Du denn mit Stromausfall, als das das nicht über Backup (das Du ja sowieso haben musst) geregelt werden kann?

USV-Störfälle

USV ist ja auch total übertrieben. Ein Stützkondensator, damit grad noch ein emergency-sync geschafft wird, reicht. :-)

 

[CommanderZed]

Da hier mehrfach btrfs erwähnt wird, wollte ich mal kurz in den Raum stellen: Ich hatte vor einigen Jahren mal ein Video mit einem Kernel-Entwickler von FreeBSD auf Youtube gesehen und der nannte btfrs als Negativbeispiel, dem er niemals seine Daten anvertrauen würde. Inwieweit das gerechtfertigt oder übertrieben ist, kann ich natürlich nicht sagen, aber ich denke, die Meinung eines FreeBSD Kernel-Entwicklers ist sicherlich keine unwichtige Meinung.

Hmmm naja einen FreeBSD Kernel Entwickler zu fragen was er von einem Linux-Dateisystem hält ist schon ein bisschen so wie einen Boing Ingenieur zu fragen was er von Airbus-Flugzeugen hält - das wird nicht die ganz neutralste Antwort sein

WAPBL scheint ja eine gute Sache zu sein. Demnach sehe ich letztendlich meine Zwischenfrage zu NetBSD und seiner Geeignetheit unter dem hier diskutierten Aspekt, Stromausfall und möglicher Datenverlust mit FFS unter OpenBSD, eigentlich beantwortet. Also abgesehen von FreeBSD, würde ich persönlich doch dann NetBSD den Vorzug für den Serverbetrieb geben.

Naja es gibt ja nur einen sehr kleinen Aspekt der hier für NetBSD spricht - eine bessere Option die man im RC setzen kann. Ansonsten sind die bei diesem spezifischen Thema ungefähr gleich auch.

Da es noch hunderte andere Variablen gibt die man bei der Frage "Was ist für mich das bessere Serversystem" beachten sollte, ist das schon etwas dünn ehrlich gesagt.
Gerade bei so Serverfragen hat OpenBSD schon einige Vorteile gegenüber NetBSD, sowohl allgemein als auch bei Detailfragen, umgekehrt aber genauso. Was davon relevant ist, muss man immer Detailiert im Einzelfall je nach Anwendungsszenario entscheiden. Und es macht auch sinn offen nach links und rechts zu schauen. FreeBSD, Linux und sogar Windows und MacOS kann unter bestimmten umständen eine sinnvollere Wahl sein.
Neben rein technischen Themen kommen auch organisatorische Fragen ins spiel, wie z.B. die eigenen Kentnisse dieser Systeme usw.

 

[Andy_m4]

das wird nicht die ganz neutralste Antwort sein

Schlechtes Beispiel. Aber ja, wir verstehen, worauf Du hinaus willst. :-)

Gerade bei so Serverfragen hat OpenBSD schon einige Vorteile gegenüber NetBSD

Sagen wir mal so:
Da man ja ohnehin Backups haben sollte und vermutlich auch nicht alle Nase lang Stromausfälle hat, kann man eh darüber streiten, wieviel Einfluss das Dateisystem hat.
Und wenn man das trotzdem als wichtig empfindet, sollte man auch All-In gehen und sowas wie ZFS nehmen anstatt jetzt da irgendwie zu grübeln ob OpenBSD-FFS und NetBSD-FFS besser ist.