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

Nun rufe ich mal kurz Microsoft in Erinnerung. Eigentlich stimmt das nicht wirklich, aber im Grunde genommen schon: Diese Firma hat seit vielen vielen Jahren NTFS und sonst nichts. Die diversen FAT wollen wir mal außen vor lassen, weil sie wiederum eigentlich keine Dateisysteme sind. Nochmal zu NTFS: es kam mit Windows NT, das war so etwa in der Mitte der 80er?

Naja, exFAT nutze ich eigentlich als Filesystem der Wahl auf USB Sticks zum Datentausch, für größere SDCards ist exFAT Standard und das FS für das die garantierten Datendurchsätze gelten. Es als "nichtmal ein Dateisystem" zu bezeichnen ist da schon etwas frech ;) .
Dann hat MS seit über 10 Jahren ReFS, das gibts zwar nicht für die Home-Versionen der normalen Enduserwindows, aber eben seit ewigkeiten auf Server und eingeschränkt auf den Pro-Versionen. Das geht stark in richtung Btrfs/zfs.
 
Naja, exFAT nutze ich eigentlich als Filesystem der Wahl auf USB Sticks zum Datentausch
metoo, also zumindest auf neueren Datenträgern, die älteren haben noch meist NTFS.
Als ich sagte, dass die FATs eigentlich keine Dateisysteme sind, wollte ich sie damit nicht schlecht reden! Ins Detail gehen, will ich nun aber auch nicht und es hätte meine Argumentation ein wenig gestört, es ganz genau nehmen zu wollen. Immerhin: sie heißen nicht mal FS (FileSystem = Dateisystem), sondern eben FAT.
Dass sie gleichwohl für ihre Zwecke ausgezeichnet funktionieren, bestärkt indessen den Kern meiner Aussage.

Dabei muss ich nun aber noch einen Schritt weiter gehen und FUSE erwähnen.
Afaik kann kein BSD von einem NTFS booten, oder einem ext4-fs. FreeBSD kann aber mittels FUSE-Modulen zur Laufzeit auf solche "exotischen" Dateisysteme zugreifen, sie auslesen und meist auch manipulieren, also wenigstens beschreiben.
Wenn ich nun OpenBSD nutzen wollen würde, wäre das für mich eine wichtige Frage: kann ich fremde Dateisysteme einbinden?
Das wäre mir wichtiger, als die Frage, welches Dateisystem OpenBSD eigentlich benutzt und welche Optionen dafür die besten sind. Ein Rescue-Stick, den man ja jedenfalls immer für sein System erstellen sollte, würde ja im Zweifel die System-Partitionen einbinden oder Reparaturen daran durchführen können.
 
Dabei muss ich nun aber noch einen Schritt weiter gehen und FUSE erwähnen.
Afaik kann kein BSD von einem NTFS booten, oder einem ext4-fs. FreeBSD kann aber mittels FUSE-Modulen zur Laufzeit auf solche "exotischen" Dateisysteme zugreifen, sie auslesen und meist auch manipulieren, also wenigstens beschreiben.
Wenn ich nun OpenBSD nutzen wollen würde, wäre das für mich eine wichtige Frage: kann ich fremde Dateisysteme einbinden?
Das wäre mir wichtiger, als die Frage, welches Dateisystem OpenBSD eigentlich benutzt und welche Optionen dafür die besten sind. Ein Rescue-Stick, den man ja jedenfalls immer für sein System erstellen sollte, würde ja im Zweifel die System-Partitionen einbinden oder Reparaturen daran durchführen können.

Wollte nachher noch 2,3 andere Gedanken schreiben, aber eben kurz damit das nicht dazwischen untergeht:

OpenBSD unterstützt FUSE und kann dadrüber auch relativ zuverlässig zb NTFS mounten, OpenBSD kann dazu nativ auch NTFS ro mounten.

FUSE ist aber nicht die stabilste Lösung denke ich.

OpenBSD unterstützt aber auch NFS so das man auch dadrüber externe Dateisysteme einbinden kann. Auch das könnte ein ergänzender Weg sein z.B. im Serverumfeld probleme zu mitigieren.
 
Afaik kann kein BSD von einem NTFS booten, oder einem ext4-fs. FreeBSD kann aber mittels FUSE-Modulen zur Laufzeit auf solche "exotischen" Dateisysteme zugreifen, sie auslesen und meist auch manipulieren, also wenigstens beschreiben.
Manchmal braucht es nicht mal FUSE. Also ja. Für exFAT und NTFS braucht man fusefs-exfat respektive fusefs-ntfs.
Aber beispielsweise ext4 geht auch mit dem System-eigenen Kernel-Treiber ext2fs. Siehe dazu auch das Handbuch:

OpenBSD unterstützt FUSE und kann dadrüber auch relativ zuverlässig zb NTFS mounten
Ja. NTFS-3G funktioniert ja so ziemlich unter jedem System. :-)

OpenBSD kann dazu nativ auch NTFS ro mounten.
Ergänzung:
mount_ntfs(8)
 
Aber beispielsweise ext4 geht auch mit dem System-eigenen Kernel-Treiber ext2fs.
nur, nicht so gut, zumindest in meiner beschränkten Erfahrung.
Tut aber auch nichts zur Sache, also es widerspricht nicht meiner Darstellung davor.

Linux kann....
Also, keine Ahnung, aber es kann unverschämt viele Dateisysteme in den Kernel integrieren. Viele Distributionen patchen hier zusätzlich was hinein, um noch flexibler zu sein. Allerdings habe ich auch da schon lange nicht mehr hingesehen.

Nochmal zu meiner Aussage:
Nimm was kommt und denk nicht zu viel darüber nach!
Bedenke, ob es FUSE (oder andere Möglichkeiten) gibt, um zusätzliche Dateisysteme einbinden zu können, falls das überhaupt erwünscht ist.

Schließlich: eigene Erfahrungen mit dem erwählten System kann kaum ein allgemeiner Rat ersetzen.
just do it...
and than, do it again...
 
Tut aber auch nichts zur Sache, also es widerspricht nicht meiner Darstellung davor.
Ja. Es ging mir auch nicht darum Dir zu widersprechen, sondern nur darum drauf hinzuweisen, das ext4 unter FreeBSD ohne FUSE geht.

Nimm was kommt und denk nicht zu viel darüber nach!
Zumindest macht man i.d.R. nichts grob falsch wenn man das von dem System vorgeschlagene default nimmt. Und man kann auch ziemlich sicher sein, das das auch vernünftig supported wird und nicht etwa irgendein Update hängt oder damit Probleme im regulären Betrieb auftreten.
 
Hardwaredefekte oder Stromausfälle und ähnliches gefallen kein Dateisystem wirklich gut.

Die Dateisysteme sind unterschiedlich tolerant ob der beiden Ereignisse. Hardwaredefekte können ZFS und btrfs immerhin feststellen (Checksum sei dank). Stromausfälle können beide auch sehr gut ab (im Gegensatz zu OpenBSDs UFS ohne soft dependencies).

Zudem ist so ein readonly-Mount ja auch eine wirksame Sicherheitsmaßnahme.

Das ist leider für /var und viele andere Partitionen nicht gangbar.

Gut. Das kann man sich ja vorher überlegen ob der Fall fürs eigene Szenario vorkommt.
Jemand der OpenBSD einsetzt und auch gezielt selber partitioniert dem trau ich das auch durchaus zu. :-)

Jede Vorhersage - auch die von Partitionsgrößen - erweist sich früher oder später gerne als falsch. :ugly:

Das insinuiert so ein bisschen, das dies eine gewollte Entscheidung ist.

Das ZFS nicht die richtige Lösung für OpenBSD ist, bin ich mir voll bewusst. Ich erwarte auch keine eierlegende Wollmilchsau. Die Abwesenheit eines robusten Dateisystems finde ich aber schon sehr befremdlich (und nicht nur ich).

OpenZFS müsste unter was (mit OpenBSD) kompatibleren als der CDDL lizenziert werden, um in OpenBSD integriert werden zu können - sagte meine ich der gute Ted Unangst (finde grad wie üblich auf die Schnelle keine Quelle mehr dazu im Netz)

Der Link müsste dieser hier sein, ist aber seit mindestens zwei Tagen down.

OpenBSD hat im Moment nicht mal die notwendigen Abstraktionslayer äquivalent zu FreeBSDs CAM oder GEOM, um überhaupt anfangen zu können.

Mir persönlich würde ja eine OpenBSD-konforme und vergleichweise simple Lösung mit Journaling völlig ausreichen. Die Entfernung von soft dependencies ist nachvollziehbar, hinterlässt aber eine schmerzhafte Lücke.

Was nützt mir das beste Dateisystem der Welt, wenn in einigen Jahren das zugehörige System eingestellt wird und ich deshalb keinen Zugriff mehr auf meine alten Daten habe?

Welches Dateisystem wurde auf eine Art und Weise abgekündigt, bei der man nicht 5 Jahre oder mehr zur Migration hatte?
 
Welches Dateisystem wurde auf eine Art und Weise abgekündigt, bei der man nicht 5 Jahre oder mehr zur Migration hatte?
irgendwie habe ich ein Problem damit, mich passend und verständlich auszudrücken, denn genau eine Diskussion um unterschiedliche Dateisysteme wollte ich ja vermeiden. Darum geht es doch hier auch nicht. Was ich wollte, war, die Frage zu entspannen.
Man kann ja schließlich nie wissen... und deshalb gibt es immer ein Risiko, man kann sich falsch entscheiden und dann lernt man halt daraus. Vorher zu denken, dass man nun alles richtig macht und das für die Ewigkeit gut ist, weil ein Guru so geraten hat, ist meiner Ansicht nach bei der Wahl der Dateisysteme verfehlt.
Glaube ich, mehr darüber zu wissen, als die Macher von OpenBSD?
Sicher nicht!
Deshalb mein Rat: nicht zu viel nachdenken, nehmen, was man dort vorschlägt, sehen, wie es sich in der eigenen Praxis bewährt und daraus womöglich lernen.

BTW: für mich selbst ist das Fehlen von ZFS ein KO-Kriterium für OpenBSD,
- aber wenn man nun mal dieses System probieren möchte, darf das eben nicht im Vordergrund stehen, welches Dateisystem mit welchen Optionen dort möglich ist. Wenn ich mal Windows probieren möchte, installiere ich es halt mit dem Dateisystem, mit dem es so daher kommt und sehe dann weiter.
 
Der Link müsste dieser hier sein, ist aber seit mindestens zwei Tagen down.
Das könnte gut sein - und auch der Grund, warum ich das auf die Schnelle nicht mehr gefunden hab.
In archive.org gibts noch eine Sicherung davon vom 18.03.2025, Ted schreibt dort über die CDDL unter anderem: "CDDL suffers from TMW. Too Many Words....I strongly believe the answer should be determinable by reading an amount of text that fits on screen with an 80x25 terminal."
Mir persönlich würde ja eine OpenBSD-konforme und vergleichweise simple Lösung mit Journaling völlig ausreichen. Die Entfernung von soft dependencies ist nachvollziehbar, hinterlässt aber eine schmerzhafte Lücke.
Ich hab als ehem. Irix-User und HPC-Cluster-Betreiber (unter Linux) immer auch etwas auf XFS in OpenBSD gehofft, aber das hatten sie vor 23(!) Jahren (2003, ich fühle mich auf einmal irgendwie alt) so beschrieben [1], In Sektion 9.1 auf Seite 86 im PDF:

"OpenBSD does NOT support Journaling Filesystems like ReiserFS, IBMs JFS or SGIs XFS. Instead we use Soft Updates" ;)

[1] https://user.phil-fak.uni-duesseldorf.de/~brakmic/doc/obsd_doc.pdf
 
Die Dateisysteme sind unterschiedlich tolerant ob der beiden Ereignisse.
Das bleibt ja unbenommen.
Aber wenn ich fsck-Vorfälle ohne größere Aufwände vermeiden kann, dann nehme ich das dankbar an.

Das ist leider für /var und viele andere Partitionen nicht gangbar.
Ja. /var hatte ich ja exemplarisch selbst genannt.

Jede Vorhersage - auch die von Partitionsgrößen - erweist sich früher oder später gerne als falsch.
Naja. Ich hab ihr ein BSD-based Router und der ist vom Speicherplatzbedarf der Partitionen jetzt schon seit Jahren ziemlich unverändert.
Aber selbst wenn da mal Speicherplatznot auftreten würde, wäre das größte Problem nicht die Partition-Größe sondern der Platz des Datenträgers. Und dann müsste ich so oder so umziehen.

Anyway: Was ich sagen will: Für manche Szenarien kann man schon halbwegs verlässliche Vorhersagen treffen. Und selbst wenn die mal nicht zutreffen, sind zu kleine Partitionen auch nicht gleich ein Weltuntergang. Also gerade heutzutage, wo man eh alles (halb-)automatisiert deployed.

Die Abwesenheit eines robusten Dateisystems finde ich aber schon sehr befremdlich
Ja.
Aber wie gesagt: Es happert auch oft an der fehlenden Manpower.

immer auch etwas auf XFS in OpenBSD gehofft
Einfach mal zum porten irgendein LLM drauf werfen.
Passt scho :-)
 
Ich hatte mir lange Zeit XFS oder ein ähnliches Dateisystem für FreeBSD und damit natürlich auch für die anderen BSDs gewünscht. Etwas, das moderner als UFS und weniger Overkill als ZFS ist. Aber realistisch gesehen wird das zumindest für FreeBSD nicht mehr passieren. UFS(2) hat seine Nachteile - u.a. bescheidene Metadaten-Performance, unter FreeBSD durch Directory Hashing mitigiert und den zwang 5 bis 8 Prozent Speicherplatz dauerhaft frei zu halten - aber ist für alle Szenarien, in denen ZFS nicht in frage kommt, locker gut genug. Umgekehrt ist ZFS Overkill durch immer schnellere CPUs und den Trend zu wesentlich mehr RAM immer weniger ein Problem geworden. Bis zu dem Punkt, dass es in vielen Fällen schlicht keinen Grund mehr gibt nicht auf ZFS zu setzen.

Unter Linux hingegen hätte ich mir wirklich gewünscht, dass bcachefs etwas wird. Es hatte alle wichtigen Features, die man von einem modernen Dateisystem erwartet und die Chance gehabt in einigen Jahren ohne Wenn und Aber robust zu sein. Etwas, was btrfs meiner Erfahrung nach nie wirklich erreicht hat. Aber Linus Torvalds hatte keine andere Wahl als Entwickler Ken Overstreet und im gleichen Schritt bcachefs rauszuwerfen und damit ist es, sofern es nicht noch eine sehr überraschende Wende gibt, erstmal zur Irrelevanz verdammt. Ein Projekt wie Linux kann halt nur funktionieren, wenn Regeln für alle Beteiligten gleich gelten und Verstöße in Fällen, wo Worte nicht mehr reichen, weitergehende Konsequenzen haben.
 
Naja, inzwischen werkel Microsoft seit Jahren an ReFS. Insofern bewegt sich hier auch etwas. Wobei ReFS an diversen Stellen noch so seine Macken hat und es auch erst jetzt auf der Systemplatte eingesetzt werden kann.

Aber zurück zu den BSDs...

HAMMER oder HAMMER2 unter OpenBSD wäre natürlich sehr cool. Gerade, wenn man OpenBSD nicht nur als Router einsetzt, wären da einige Features natürlich sehr nützlich. Ich fand das unter DragonFlyBSD schon sehr gelungen. Aber aktuell will DragonFlyBSD auf dem Desktop mit der Intel Grafik nicht so wirklich. Eine zeitlang hatte ich das mal als Desktop und das lief wirklich problemlos. Man musste nur sehen, dass regelmäßig die Cleanup Jobs liefen, damit die Platte nicht von den ganzen Snapshots gefüllt wurde. Das System gefällt mir echt gut, wobei die meines Wissens noch weniger Manpower haben als OpenBSD.

Zurück zum Thema...

Bei mir werkel seit Jahren ein kleiner Mini-ITX unter OpenBSD als Server für Mail, Matrix und weitere Spielereien. Der läuft permanent mit einer SSD, die 24/7 tauglich ist. Der hatte leider auch schon mal den einen oder anderen harten Reset (Stromausfall). Auch auf meinem ThinkPad läuft OpenBSD. Und dort gab es ab und an mal Probleme mit dem Boot nach Hibernate, da bootete der Kernel normal und wollte das Hibernate File nicht nutzen. Folge war dann ein fsck. Vielleicht hatte ich bisher Glück, aber verlorene Files oder richtig kaputte Dateisysteme hatte ich bisher bei OpenBSD nicht. Und bisher hatte ich softdep dort immer aus.

Auch wenn die Wahl wohl inzwischen zugunsten von FreeBSD gefallen ist, würde ich da nicht allzu viel Angst vor Datenverlust seitens FFS haben. Wichtig sind vor allem regelmäßige Backups. DIe helfen auch bei kaputten Platten. Und klar ist vieles unter FreeBSD flotter oder zumindest hat man den Eindruck, aber die Frage ist ja häufig, ob das nötig ist.

Und Updates finde ich unter OpenBSD deutlich entspannter als unter FreeBSD. Insbesondere sysupgrade läuft einfach inklusive Report via Mail an Ende. FreeBSD hat hier bisher auch keine wirklichen Probleme verursacht, nur die Quartalsupdates der Ports haben schon mal die eine oder oder andere Überraschung verursacht.
 
Unter Linux hingegen hätte ich mir wirklich gewünscht, dass bcachefs etwas wird. Es hatte alle wichtigen Features, die man von einem modernen Dateisystem erwartet und die Chance gehabt in einigen Jahren ohne Wenn und Aber robust zu sein. Etwas, was btrfs meiner Erfahrung nach nie wirklich erreicht hat. Aber Linus Torvalds hatte keine andere Wahl als Entwickler Ken Overstreet und im gleichen Schritt bcachefs rauszuwerfen und damit ist es, sofern es nicht noch eine sehr überraschende Wende gibt, erstmal zur Irrelevanz verdammt. Ein Projekt wie Linux kann halt nur funktionieren, wenn Regeln für alle Beteiligten gleich gelten und Verstöße in Fällen, wo Worte nicht mehr reichen, weitergehende Konsequenzen haben.

Interessant wie schwer man (bzw. ein Dateisystem) einen schlechten Ruf loswird. Btrfs ist neben XFS sich das am meisten bei uns im Betrieb und bei Kunden eingesetzte FS, es ist Default oder wird zumindest von vielen Enterprisedistros unterstützt (SUSE, Oracle, Ubuntu) und wird auch auch von vielen großen Firmen massiv benutzt. Wenn man die Features auslässt, die als unstable markiert sind, erhält man ein absolut stabiles FS, ich hätte noch keinen einzigen Ausfall damit erlebt. Klar das ist persönliche Evidenz und auch nur ~50 Setups aber dennoch. Unter ext3/4 habe ich tatsächlich schon 2 mal Datenverlust erlebt (allerdings zugegeben auch schon über 10 Jahre her, da hat sich viel getan). Das einzige was man ihm ankreiden kann, ist die nicht verhandene DAU-Sicherheit, man kann schon viel falsch machen, wenn man nicht weiß, was man tut.

Was bCache betrifft: Das war ein schöner Traum, aber mit Kent gabs ja soweit ich weiß schon vorher Probleme (irgendwas mit dem Cryptostack).
 
Und gerade HAMMER2 wurde ja auch ein bisschen so in Hinblick auf Portierbarkeit entwickelt.

Interessant wie schwer man (bzw. ein Dateisystem) einen schlechten Ruf loswird.
Wobei jetzt Linux-Kernel-Entwickler allgemein nicht gerade von sozialer Kompetenz strotzen. :-)
Aber ja. Selbst da gibts natürlich Grenzen.

Mit ReiserFS gabs ja schon mal ein vielversprechendes Dateisystem, welches so ein bisschen unter seinem Hauptentwickler gelitten hat.
 
Interessant wie schwer man (bzw. ein Dateisystem) einen schlechten Ruf loswird. Btrfs ist neben XFS sich das am meisten bei uns im Betrieb und bei Kunden eingesetzte FS, es ist Default oder wird zumindest von vielen Enterprisedistros unterstützt (SUSE, Oracle, Ubuntu) und wird auch auch von vielen großen Firmen massiv benutzt.

Ja, das ist zu 98% Psychologie. Ich bin da nur gerade gebranntes Kind, weil die Kollegen vom Betrieb mit der USV Mist gebaut hatten und durch den Stromausfall alles bis auf ein nicht unwichtiges btrfs überlebt hat. Was sich dann aber auch gleich so zerlegt hat, dass ich zum Backup greifen durfte. Aber das ist natürlich anekdotisch und auch wieder die Frage, wie genau Dells SSDs es mit der Wahrheit nehmen.
 
Mit ReiserFS gabs ja schon mal ein vielversprechendes Dateisystem, welches so ein bisschen unter seinem Hauptentwickler gelitten hat.
Btrfs ist neben XFS sich das am meisten bei uns im Betrieb und bei Kunden eingesetzte FS,
ReiserFS litt aber schließlich nicht unbedingt an den Unarten seines Inspirators, obwohl, wenn ich recht entsinne, dieser wegen eines Tötungsdeliktes von der Bildfläche gezwungen wurde und deshalb auch nicht weiter in die damals aktuelle Entwicklung eingreifen konnte, sondern hier war einfach eine Notwendigkeit erkannt worden, ext2 zu modernisieren und mit ext3 schließlich auch ein recht guter Weg eingeschlagen worden, so dass viele Distros den zwischenzeitlichen Hype mit ReiserFS wieder ablegten.
Zuletzt noch hatte ich mit Knoppix einen aktiven Einsatz von ReiserFS erlebt. Der Entwickler Klaus Knopper vertraute für seine "KNOPPIX-DATA"-Partition darauf und fand es zuverlässiger, als andere Lösungen. Ich selbst bevorzugte hier ext2, testete aber auch BTRFS erfolgreich.

Als ich vor gefühlten Ewigkeiten noch an Linux hing, probierte ich viele Dateisysteme aus und das kann man da auch tun, weil direkt im Kernel schon sehr viele Möglichkeiten vorhanden sind (oder sich doch bereit stellen stellen). Damals blieb ich in der Tat auch bei XFS hängen und verstand da schon nicht, warum man unbedingt immer wieder neue Dateisysteme bauen muss, wenn man doch eines hat, das alles so hervorragend kann.
Zuletzt hatte ich bei meinen Installationen ext4 und BTRFS probiert und zugegeben, ext4 erscheint einfacher und per default auch leicht performanter, was aber immer eine gewagte Behauptung ist. Wenn man hier bei "Default" bleibt, hat man vielleicht gar keinen so großen Nutzen von dem, was einem BTRFS an "Mehr" so bietet. Folglich bleibt es nicht beim Default und da zeigt BTRFS in meinen Augen schon deutliche Vorteile, die sich zB durch schnelle Kompression schließlich auch vorteilhaft auf Performance auswirken können. Also, obwohl es mir sehr schwer fällt, damit umzugehen, ziehe ich es nach meinen letzten Erfahrungen für Linux doch vor.
Und warum kein ZFS auf Linux?
Das habe ich einmal getestet und damals war es für mich recht kompliziert, das Linux zum Booten von ZFS zu bewegen. Deshalb habe ich ZFS bei meinen Linux-Sticks nur zusätzlich angelegt, um evtl mal einen Pool einbinden zu können. Das ist aber in meinem Fall eine Dummheit gewesen, denn ich benutze Linux nicht aktiv, vernachlässige Updates total und kann dann schließlich neuere Pools doch nicht mehr einbinden, wenn es neue ZFS-Versionen gibt.
Da mich IT nur am Rande und als Endanwender interessiert, habe ich mich final für FreeBSD entschieden und will nicht noch großartig weitere Erfahrungen im Linux-Land machen.
Aber tatsächlich fand ich eben BTRFS viel besser, als sein Ruf und habe nur einmal Daten verloren, als ich den damals noch angebotenen Mechanismus nutzen wollte, zurück zu ext3 zu gehen.
 
Ja, das ist zu 98% Psychologie. Ich bin da nur gerade gebranntes Kind, weil die Kollegen vom Betrieb mit der USV Mist gebaut hatten und durch den Stromausfall alles bis auf ein nicht unwichtiges btrfs überlebt hat. Was sich dann aber auch gleich so zerlegt hat, dass ich zum Backup greifen durfte. Aber das ist natürlich anekdotisch und auch wieder die Frage, wie genau Dells SSDs es mit der Wahrheit nehmen.
Systeme auf denen ich btrfs einsetze: 1
Systeme, auf denen ich heute Datenverlust nach Stromausfall hatte: 1
 
wie genau Dells SSDs es mit der Wahrheit nehmen.
Dazu kommt noch die Überraschungstüte, was einem die Firmware diesmal ans Bein pinkelt. :D
 
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.

(TBF wurde angemerkt, wie auch wie von @Yamagi erwähnt, das komplexere Filesysteme wie ZFS wenn etwas schief läuft es halt richtig schief läuft.)

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. 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 .

Meine Erfahrung ist halt, wie @Azazyel eine andere, auch auf den Mailinglisten tauchen ab und an mal entsprechende leute auf.

Ich glaube angesichts der aussagen dort das auch ein evtl. Lizenzmäßig passendes "HAMMER2" eher nicht in nächster Zeit kommt.

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.
Und das waren teilweise auch wirklich von hunderten Benutzern gleichzeitig genutzte Produktivsysteme (Jaja ich weiß für manche hier peanuts :D - aber schon etwas mehr als nen Homeserver)
Das ist imho schon nen ganz schöner Unterschied zu FFS unter OpenBSD in realen Anwendungen.

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.

ReiserFS litt aber schließlich nicht unbedingt an den Unarten seines Inspirators, obwohl, wenn ich recht entsinne, dieser wegen eines Tötungsdeliktes von der Bildfläche
Nur als kleine Anmerkungen, er wurde rechtskräftig wegen Mordes an seiner Ehefrau verurteilt.

Davon unabhängig: Der Code wurde wohl auch nicht so mega gut weitergeführt weil er wohl auch innerhalb der Entwicklercommunity mit wenigen oder sogar niemanden so richtig gut zusammenarbeitete und somit niemand das so richtig gut fortführen konnte (Gefährliches Hörensagen) - das ist natürlich nicht so komplett unabhängig dann von der Tat.
 
Ich verwende OpenBSD mit ffs seit vielen Jahren auf diversen Servern in der Firma und auch privat. Diese laufen 24/7 und werden nur bei notwendigen Patches oder zu neuen Release geupdated und neugestartet. Ich hatte in all den Jahren keine freezes und auch keine Datenverluste. Auf dem Server laeuft OpenBSD rock solid. Anders sieht es aber unter Consumer-Hardware aus. Dort hatte ich im Gegensatz zu den Servern auch schon freezes und meine Dateisysteme sind hier auch alle verschluesselt. Zum Datenverlust oder nicht mehr bootbaren Systemen ist es aber in all den Jahren nie gekommen. Ich denke, wenn mir das oefter passieren wuerde, haette ich auch eine andere Sichtweise. Aber so bin ich halt zufrieden und vermisse kein anderes Dateisystem.
 
Ich verwende OpenBSD mit ffs seit vielen Jahren auf diversen Servern in der Firma und auch privat. Diese laufen 24/7 und werden nur bei notwendigen Patches oder zu neuen Release geupdated und neugestartet. Ich hatte in all den Jahren keine freezes und auch keine Datenverluste. Auf dem Server laeuft OpenBSD rock solid. Anders sieht es aber unter Consumer-Hardware aus. Dort hatte ich im Gegensatz zu den Servern auch schon freezes und meine Dateisysteme sind hier auch alle verschluesselt. Zum Datenverlust oder nicht mehr bootbaren Systemen ist es aber in all den Jahren nie gekommen. Ich denke, wenn mir das oefter passieren wuerde, haette ich auch eine andere Sichtweise. Aber so bin ich halt zufrieden und vermisse kein anderes Dateisystem.

Beruflich hab ich (fast) nie OpenBSD eingesetzt, da kann ich also nicht so viel zu sagen.

Wo ich kaum bis gar keine Probleme hatte sind Thinkpads gewesen, da lief das immer Rock-Solid, sicher auch weil die Hardware sehr gut unterstützt ist, gerade wenn man 2 Jahre alte gebrauchtgeräte gekauft hat wie ich damals, kombiniert mit halt einer integrierten "USV".

Auch sehr problemfrei war z.B. immer mein China "QUTOM" Router, das lief auch problemfrei, hatte aber keine USV und da musste ich bei nem kurzen Stromausfall so manches mal das Gerät unterder Kellertreppe entfernen und an nem HDMI oder an die Serielle Konsole hängen um das per fsck zu lösen.

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.

Anfangs völlig problemfrei kamen mit irgend einen OpenBSD Update ein neues Intel-DRM Release und da hatte ich ewig freezes bis ich herausgefunden hab das es an dem DRM ding lag und ich dem Kernel beigebracht hatte das nicht mehr zu laden. Das war auch nerfig weil das Gerät eigentlich "headless" lief und die 4TB Sata-SSD nen großes Dateisystem mit vielen kleineren Files halt ewig zum Check gebraucht hat. Teilweise hat dann aber noch im check dsa DRM wieder ne Panic gebaut, solange ich es nicht über den RD gestartet hatte, der RD hatte das Problem nicht.

Die aktuelle QEMU-VM läuft dagegen problemlos, dito auch über viele Jahre eine netcup-vm, zumindest in der hinsicht.
 
Zurück
Oben