PC-BSD 7.1.1: "UFS2 + Journaling" ??
- Ersteller mawei
- Erstellt am
(bezieht sich jetzt mehr auf FreeBSD):
Wenn Softupdates keine Vorteile bietet, in welche Richtung geht es dann zukünftig? Wird "UFS2 + Journaling" zur Standardeinstellung (weil besser zu maintainen) und Abschied genommen von Softupdates oder bleibt Softupdates für immer Standard?
Softupdates bleiben. Sie haben den Vorteil, dass sie atomar konsistent sind. Das heißt, da das Dateisystem nie die konsistenz verliert, hast du auch nie Ärger. Zumindest bei entsprechender Hardware, bei Desktop-Hardware muss man da schon den berüchtigten Write Cache abschalten, was einen massiven Verlust an Datendurchsatz bedeutet. Daher brauchen Softupdates an sich auch kein fsck. Das fsck ist aus zwei Gründen nötig, einmal um noch als belegt markierten Speicherplatz freizugeben und dann um die Beschränkungen unserer minderwertigen Hardware auszugleichen. Auf den dicken SAS-Arrays mit BBU habe ich z.B. das fsck komplett ausgeschaltet und mache alle paar Monate mal eines im Hintergrund. Klappt astrein, aber auf dem Desktop kaum möglich.
Journaling hat den umgekehrten Ansatz. "Wir machen das Dateisystem kaputt, merken uns aber, was wir zerlegen und reaprieren es anschließend wieder". Hat den Vorteil, dass man kein fsck braucht, niemals. Den Nachteil, dass im schlimmsten Fall die Reparatur nicht mehr möglich ist. Auf dem Desktop wird dies wieder von Write Cache unterlaufen, weshalb Journaling ein geringfügig größere Risiko darstellt. Auf dem Server mit entsprechender Hardware gibt es praktisch keine Vorteile, im Gegenteil.
Vor daher ist es in der Desktop-Praxis eine Frage des Geschmacks. Für die Zukunft wäre es vielleicht denkbar gjournal zu töten und WAPBL von NetBSD zu protieren. Es ist in das Dateisystem integriertes Journaling und hat einige kleinere Vorteile. Oder man lässt es alles und nimmt gleich ZFS...
Journaling hat den umgekehrten Ansatz. "Wir machen das Dateisystem kaputt, merken uns aber, was wir zerlegen und reaprieren es anschließend wieder". Hat den Vorteil, dass man kein fsck braucht, niemals. Den Nachteil, dass im schlimmsten Fall die Reparatur nicht mehr möglich ist. Auf dem Desktop wird dies wieder von Write Cache unterlaufen, weshalb Journaling ein geringfügig größere Risiko darstellt. Auf dem Server mit entsprechender Hardware gibt es praktisch keine Vorteile, im Gegenteil.
Vor daher ist es in der Desktop-Praxis eine Frage des Geschmacks. Für die Zukunft wäre es vielleicht denkbar gjournal zu töten und WAPBL von NetBSD zu protieren. Es ist in das Dateisystem integriertes Journaling und hat einige kleinere Vorteile. Oder man lässt es alles und nimmt gleich ZFS...
Entsprechende Hardware (also Festplatten oder Controller??) heisst dann was konkret?
Wenn das Abschalten des Write Cache bei Desktop-Systemen nicht sinnvoll ist, dann ist der Einsatz von Softupdates in diesen Fällen nicht praktikabel. Habe ich das so richtig verstanden?
Hmm, auf die Freigabe von freiem Speicherplatz möchte der Anwender sicher nicht verzichten. Also bleibt fsck doch eine Notwendigkeit, oder??
"unsere minderwertige Hardware" heisst Desktop Festplatten/Controller, oder? Dann könnte man doch einfach mit hochwertigen Komponenten nachrüsten.
Naja ;-) Mir hat es dann gestern mit UFS2+Journaling unter PC-BSD das Dateisystem zerlegt! Ertes Booten nach der Installation klappte noch. Irgendwann hat der Laptop sich dann abgeschaltet (Akku war halt leer). Beim nächsten Booten war das System dann hinüber. Keine Ahnung wie ich das repariert bekomme. Aber ist ja ziemlich schnell neu installiert.
Professionelle SAS-Systeme (SAS == Serial Attached SCSI) mit batteriegepuffertem Cache und mit SAS-Platten daran. Schraubt man S-ATA Platten ran, rennt man wieder in Probleme.
Ja hast du. Denn der Write Cache als weitere Ebene zwischen Betriebssystem und Medium macht es schlicht unmöglich, gewisse Grundvoraussetzungen zu garantieren, auf denen Softupdates basieren. Aber exakt das Gleiche gilt auch für Journaling. Ist der Write Cache an, funktioniert auch das Journal nicht mehr korrekt, mit entsprechenden Folgen.
Wir reden hier von wenigen Kilobyte bis Megabyte. Das sind Mengen, die im Zeitalter von Festplatten von 2TB irrelevant sind. Zumindest so irrelevant, dass man das fsck für Stunden oder Tage verschieben kann.
Könnte man, ja. Aber dann wäre das Storage-System schlicht deutlich teurer als der ganze Rechner außen rum. das rechnet sich schlicht nicht
Wie defekt? Ich habe es in 13 Jahren noch nicht geschafft, ein FFS-Dateisystem endgültig zu zerlegen. Auch wenn teilweise nach wirklich dummen Aktionen, für die das Dateisystem aber nicht konnte, harte Maßnahmen wie fsdb(8) nötig waren. Mit FreeBSD 8.0 wird es noch einmal ein deutlich verbessertes fsck geben, was diverse randfälle abdeckt, die man bisher manuell regeln musste...
Nein. Bei 5.x haben mich die Soft-Updates das letzte mal im Stich gelassen. Seitdem haben alle meine UFS+Softupdates Partitionen wirklich böse Abstürze, während großen Schreiborgien schadlos überstanden, ohne das dabei Datenverluste (abgesehen halt von den Daten die während den letzten paar Sekunden geschrieben wurden).
Ich gehe davon aus, dass inzwischen auch die Consumerplatten entsprechend dimensionierte Kondensatoren haben um gecachte Daten bei einem Stromausfall noch fertig zu schreiben, so dass trotz Write-Cache das Soft-Updates Konzept funktioniert.
Ich gehe davon aus, dass inzwischen auch die Consumerplatten entsprechend dimensionierte Kondensatoren haben um gecachte Daten bei einem Stromausfall noch fertig zu schreiben, so dass trotz Write-Cache das Soft-Updates Konzept funktioniert.
lme
FreeBSD Committer
Mit PC-BSD und UFS+Journalling habe ich auch schon 2x die Installation nach einem Crash so kaputt bekommen, dass es nicht weiter als in den Single User Mode gekommen ist.
Da wars einfacher neu zu installieren als das zu fixen.
Die Journalling-Umsetzung in PC-BSD scheint nicht so toll umgesetzt zu sein, vielleicht ists aber auch ein Fehler von FreeBSD.
Da wars einfacher neu zu installieren als das zu fixen.
Die Journalling-Umsetzung in PC-BSD scheint nicht so toll umgesetzt zu sein, vielleicht ists aber auch ein Fehler von FreeBSD.
Daemotron
Well-Known Member
Es sind nicht nur billige Platten und Controller, die hier den Kummer für die FS-Entwickler bereiten, sondern letztlich ist es der ganze kaputte Bastelramsch, der heute den Standard-PC (x86 bzw. x86_64) ausmacht. So gibt es z. B. keinen Standard-Bus, der Informationen über einen Spannungsabfall am Netzteil und andere Störmeldungen an die übrigen Komponenten weiterreicht (in professioneller Data Center Hardware != x86 ist so etwas üblich). Also muss man mit BBUs oder Kondensatoren in den Platten dieses Übel ausbügeln, aber letztlich ist es nur ein Drumherum-Gefrickel.