UFS2 & Erklärung Dateisystem (softupdates)

[pertze]

hoi hoi

wenn das 5.2er release rauskommt soll ja ungefähr auch der 5er branch stable werdn, ned?
heißt das dann auch das nun auch die 5er im produktiven einsatz eingesetzt werden können?

wenn ja, dann heißt das ja auch dass das ufs2 zum einsatz kommen würde, aber ist das denn schon ausgereift? ich mein wenn das da das standard fs sein soll ... hmm ...

und wieso steht uns noch ein 4.9 release bevor wenn der 5er branch stable wird? was hatn das fürn sinn *grübel*

vinc

edit:
ich frage deshalb, weil ich meinen redhat 8.0 server mit 120gb hdd durch nen dual pentium pro erstetzen will
ich warte nun noch sehnsüchtig auf 5.2 da dort ja beispielsweise das kse (m:n threading) stable is
das umstellen auf ein neues filesystem möchte ich mir aber nur einmal antun, bei 80gn daten verständlich oder?
drum interessiert mich inwieweit man ufs2 als sicheres fs bezeichnen kann ...
ps: ich weiß dass man auch ufs1 wählen kann, aber das neue fs soll ja so toll sein :>

 

[current]

Der wesentliche Unterschied zwischen UFS1 und UFS2 ist die Speicherung der Metadaten der Files. Dazu musste die Grösse der entsprechenden Strukturen angepasst werden. Gleichzeitig sind noch neue Features wie ACL's usw. eingeführt worden.

Was wichtig ist: Die grundsätzlichen Algorithmen der Verwaltung von Files sind zwischen UFS1 und UFS2 gleich! Und deshalb lässt sich Deine Frage

drum interessiert mich inwieweit man ufs2 als sicheres fs bezeichnen kann ...

nur so beantworten: UFS2 ist *genauso* sicher wie UFS1. Punkt.

 

[pertze]

cool
na dann bin ich beruhigt!

danke, vinc

 

[Ripley8]

Definiert doch bitte mal "sicher".
Meint ihr sicher im Sinne von Benutzerrechten oder im Sinne
von Zuverlässigkeit?
Wenn letzteres möchte ich sagen, dass auch bei gleichen
Algorithmen für die Verwaltung der Code von ufs2 vermutlich
doch einigen Änderungen unterzogen ist und daraus folgt,
dass er nicht zwangsläufig schon so zuverlässig sein muss,
wie der Code von ufs1.

Das heisst jetzt aber auch nicht, dass ufs2 besonders
unzuverlässig sei. Nur, dass es natürlich neue Bugs geben
kann.

 

[current]

Wenn letzteres möchte ich sagen, dass auch bei gleichen
Algorithmen für die Verwaltung der Code von ufs2 vermutlich
doch einigen Änderungen unterzogen ist und daraus folgt,
dass er nicht zwangsläufig schon so zuverlässig sein muss,
wie der Code von ufs1.

Vielleicht habe ich mich unklar ausgedrückt, aber UFS1 und UFS2 benutzt nicht nur die *gleichen* Algorithmen, sondern den *gleichen* Code. Was sie unterscheidet sind die Metadaten, die bei UFS2 in einer erweiterten, grösseren Struktur untergebracht sind...

Das heisst jetzt aber auch nicht, dass ufs2 besonders
unzuverlässig sei. Nur, dass es natürlich neue Bugs geben
kann.

Da stimme ich Dir zu.

 

[Ripley8]

Achso, sogar der selbe Code.
Das ist natürlich gut :-)

Aber es genügt ja auch, wenn ein Bug im Code für die neuen
Metadaten drin ist...

Ich denke mal, die Programmierer vom Filesystem werden
sehr viele Tests machen, bevor sie etwas ins CVS geben...

 

[buebo]

Stable heisst ja nur das das FreeBSD-Project den Code als Stabil ansieht, nicht das nun durch einen magischen Prozess UFS2 auch 10 Jahre an Erfahrungsschatz gewinnt :-)

buebo

 

[pertze]

naja mir geht es vorrangig um die zuverlässigkeit
das gleiche thema war ja auch unter linux ne disskussion:
ich habe lieber das augereifte ext2 genommen, statt ext3 oder reiserfs

und von der performance her bringt ufs2 bei nem stinknormalen x86 rechner nix oder?

 

[asg]

Servus.

Original geschrieben von vincent v.
naja mir geht es vorrangig um die zuverlässigkeit
das gleiche thema war ja auch unter linux ne disskussion:
ich habe lieber das augereifte ext2 genommen, statt ext3 oder reiserfs
und von der performance her bringt ufs2 bei nem stinknormalen x86 rechner nix oder?

Naja, der Unterschied mit ext2 und ext3/reiserfs hinkt etwas.
Das was Du meinst ist das Zusatzfeature "softupdates", welches als journaling filesystem next generation gehandelt wird. Dadurch ist auch kein fsck mehr beim booten nötig wenn die Kiste absemmelt, sonder es wird ein bgfsck gestartet.
Eine Inkonsitenz des Dateisystem kann eigentlich nicht auftreten, im Vergleich zu anderen Dateisystemen. Interessant ist auch das "snapshot" feature.
Aber das geht nun ganz am Thema vorbei.

Ansonsten ist der Unterschied von UFS1 und UFS2 geringer als man evtl. denkt, der Unterschied liegt meist in sofupdates, ob das an oder aus ist.

So wurden bei UFS2 einige Datenfelder erweitert, so stellt die Größenbeschränkungen von Dateien, Filesystemen, und Anzahl von
Inodes für die nächsten X Jahre kein Problem da.
Achja, und dann waren da noch die ACLs, wobei das auch mit UFS1 geht, wenn ich nicht irre, es aber ander gehandelt wird.

 

[Ripley8]

Softupdates hilft aber auch nur gegen ungewollte dirty reboots.
Als mir die eine Platte an Karfreitag am Sterben war, hat das
auch nichts genutzt, da hat dann der fsck nur noch was von
softupdate inconsistency gelabert und fertig.

Massig kaputte Datenbereiche (zum Teil flächendeckend)
sind aber auch die Ausnahme schlechthin und wenn ich es
mir hätte leisten können, hätte ich die Platte nicht für einen
Garantieaustausch an Maxtor geschickt, sondern mir nur eine
neue gekauft und das Gerät einem FS-Entwickler als Testfeld
zur Verfügung gestellt.
Mich täte ja interessieren, was an der Platte nun kaputt
gewesen ist, aber leider hat mir Maxtor keine Mail geschickt
um die ich sie gebeten hatte (durch beiligende Notiz).

Vielleicht sind die Zeiten, wo so ein Gerät dann in ein Labor
zur Analyse geht inzwischen für Consumer-IDE Ranz auch
vorbei, so dass die Leute sie vielleicht maximal einmal an
einen Rechner gesteckt haben um den Fehlercode der
Diagnosesoftware nochmal zu prüfen und sie dann direkt in
die grosse Rundablage gewandert ist.

 

[buebo]

Original geschrieben von Ripley8
Softupdates hilft aber auch nur gegen ungewollte dirty reboots.
Als mir die eine Platte an Karfreitag am Sterben war, hat das
auch nichts genutzt, da hat dann der fsck nur noch was von
softupdate inconsistency gelabert und fertig.

Verständnissfrage:
Ich bin bis heute davon ausgegangen das gegen eine kaputte Platte auf Filesystem ebene eigentlich gar nichts getan werden kann, sondern dazu ein raid her muss, liege ich da falsch?

 

[cirad]

@buebo:
Nein, eigentlich liegst du da richtig. (: Außer, daß Bad Blocks im FS markiert und umgangen werden können (ob das bei UFS geht weiß ich nicht). Aber die Daten an diesen Stellen sind so oder so hin.

 

[Ripley8]

Das hängt ja auch stark davon ab, wie die Platte ausfällt.

In meinem Fall war es so, dass ich gerade ein paar grosse
Files verschoben hatte und das Schreiben fehlschlug, bzw.
halt gerade die Fehler nicht bemerkt wurden und die Blöcke
mit den Daten anschliessend defekt waren.

Es wäre schon gut, wenn es Fallback-Strategien gäbe, die bei
Lowlevelfehlern bei Schreiboperationen dafür sorgen, daß die
Daten dann an anderer Stelle abgelegt werden.

Ich weiss aber nicht, ob die Datenstrukturen im Filesystem
hinreichend variabel sind, dass die Metadaten an anderer
Stelle liegen dürfen.

 

[asg]

Moin.

Wenn die Platte wirklich böse absemmelt, und gleich mehrere Bereiche zerstört, dann ist es egal welches Filesystem man nutzt, die Platte ist hinüber, die Daten ebenso. Aber in Zeiten in denen Platten nicht mehr das sind was sie mal waren, macht ja jeder von uns sein Backup, oder?

Noch was zu UFS und softupdates.
UFS+softupdates rennt sehr sehr gut, man sollte sich nur an eine Kleinigkeit halten, dem abschalten des write caches bei den Festplatten. Hat den entscheidenden Nachteile, das diese billige Technologie, auch bekannt als IDE, dann heftig in die Knie geht, Performanceverluste. Zuerst die Sicherheit, dann die Performance....
Bei SCSI hingegen funktioniert das sog. tagged command queuing ohne Probleme, daher sollten die Einbußen hier nicht zu spüren sein.

Wenn ich das was ich über softupdates gelesen habe richtig verstanden habe, dann verhält sich dies so:

Es gibt erstmal zwei typische Szenarien bei den Dateisystemen wie die sog. Metadaten des Dateisystems (update i-node Bereiche) auf die Platte geschreiben werden.

1. synchrone updates der Metadaten
Bei Änderungen an einem verzeichnis wurde gewartet bis die Änderungen zurückgeschrieben worden sind (wobei die eigentlichen Daten im buffer cache zwischengespeichert wurden und danach asynchron zurückgeschrieben wurden).
Der Vorteil ist die Sicherheit. Der Nachteil das Änderungen (Metadaten) eher lansgam bis schleichend vorangeht.
Zur Sicherheit noch was, die Metadaten sind prinzipiell immer konsistent, soll heissen, entweder ist eine Datei komplett angelegt, oder komplett fehlend, dies wiederum kann das fsck feststellen und reparieren, Dateilänge wird auf 0 gesetzt.

2. asynchrone Metadaten updates
Der Standard bei ext2fs und bei den BSDs mit "-o async" zu erzielen.
Was ist nun das Geheimnis? Die updates der Metadaten werden auch einfach über den buffer cache geschoben, so ist ein warten auf das Update nicht mehr nötig, was sich wiederum in der schnelleren Geschwindigkeit bemerkbar macht.
Der grosse Nachteil aber ist, das niemand für die Konsistenz des Filesystems garantieren kann. Stolperte man nun während einer grösseren Operation (viele Metadaten werden gepackt == tar -x oder ähnliches) über den Netzstecker und die Kiste fällt runter, dann herrscht ein gewisses durcheinander im Filesystem.
Das Problem dabei ist nun, das es schwer zu beurteilen ist was schon geschrieben wurde und was noch nicht. So können von einer Datei schon gewissen Datenblöcke vorhanden sein, aber die updates der i-nodes und/oder Verzeichnis noch nicht geschrieben wurden. Ouch.
fsck steht nun auch auf dem Schlauch, da die wichtigen Informationen einfach fehlen.
Naja, es gab dann wohl diesen Ausweg der sich "dirty region logging" nannte, bzw. nennt. Metadaten-Updates werden synchron geschrieben, aber nur in einer sog. logging area, und von dieser werden diese wiederum asynchron in die eigentlich vorgesehenen Bereichen geschrieben.
Wo liegt dann aber der Geschwindigkeitsvorteil gegenüber Variante 1?
Nun, diese logging area ist ein zusammenhänges Teilstück auf der Platte, die Köpfe dieser müssen keine grossen Wege zurücklegen wie es bei Variante 1 der Fall ist == schneller.
Der Vorteil liegt auf der Hand, kommt es zum Ausfall während einer grösseren Operation, so kann die konsistenz dadurch erreicht werden, das Operatioen aus der dirty region log zuende geführt wurden, oder auch nicht, was schneller geht als ein volles fsck.

3. softupdates
McKusick hat nun folgendes gemacht. Die nötigen Updats der Metadaten bleiben im Speicher und werden dann sortiert auf die Festplatte geschrieben (wenn ich nicht irre: ordered metadata updates oder ähnlich ;-)).
Der Effekt ist, das wenn viele Metadaten-Operationen stattfinden, immer die nächste Operation die vorhergehende im Speicher sozusagen einholt.
Nun werden die Operationen in der Regeln im Speicher abgwickelt bevor der Update auf die Platte geschrieben wird, die zugehörigen Datenblöck werden sortiert das sie nicht vor den Metadaten auf der Platten landen.
Kommt es nun zu einem crash, kommt es zu einem sog. log rewind.
Alle Operationen die noch nicht auf der Platte sind sehen danach aus als wenn diese nie stattgefunden hätten. Dies wiederum bringt einem einen konsistenten Zustand den man mit "ein wenig früher" bezeichnen könnte.
McKusick "garantiert" mit dem Algorythmus, das die benutzten Ressourcen auch in der i-node Tabelle als belegt markiert sind, so kann es eigentlich nur passieren, dass Resourcen noch als belegt markiert sind die eigentlich gar nicht belegt sind, was wiederum einen fsck braucht.
Hier nun kommt das backgrund fsck ins Spiel (bgfsck). Es wird ein sog. snapshot des Dateisystems gemacht (snapshots eigenen sich auch sehr gut für backups, siehe "man mount"), und dies kann im Hintergrund passieren, und gibt evtl. nicht benötigte Ressourcen wieder frei. Neben jails finde ich snapshots und die Idee von McKusick sehr faszinierend :-).
Was ist nun der Vorteil? Metadten Operationen laufen beinahe so schnell wie im asynchronen Fall, oder gar schneller könnte man behaupten, dennm wir erinnern uns, beim sog. journaling müssen die Metadaten immer 2x geschrieben werden.
Wozu braucht man dann also bei FreeBSD bitte ein JFS?
Nachteilig ist der erhöhte Speicherverbrauch und der wohl komplexe Code, zumal man sich nicht wundern darf, wenn nach einem crash ein etwas älterer Stand vorzufinden ist.

Soviel dazu.
Ich hoffe das ich McKusick richtig verstanden habe, das es der Leser hier versteht, und ich meine Quellen richtige zusammensortiert habe.
Es gibt einige papers zu softupdates, leider habe ich gerade nur einen link parat:
http://www.mckusick.com/softdep/index.html

 

[moonlook]

Bei SCSI hingegen funktioniert das sog. tagged command queuing ohne Probleme

Bei IDE-Platten auch, sie müssen nur neuerer Natur sein und von IBM/Hitachi kommen
Ist mir die einzig bekannte Firma, die dies Feature auch bei IDE implementiert hat.

Der Eintrag dazu in der /boot/loader.conf:
hw.ata.tags="1"
Das tag queuing wird dann bei Platten eingeschalten, die dies unterstützen, bei anderen nicht.

Beim dmesg macht sich das dann folgendermassen bemerkbar (man sieh den Unterschied zwischen einer WD und einer IBM):
ad0: 76319MB <WDC WD800JB-00CRA1> [155061/16/63] at ata0-master UDMA100
ad1: 78533MB <IC35L080AVVA07-0> [159560/16/63] at ata0-slave tagged UDMA100

abschalten des write caches bei den Festplatten

Geht, falls sich jemand fragt, durch einen Eintrag in der /boot/loader.conf: hw.ata.wc="0"
Mit dem Wert 1 schaltet man dies wieder ein.