CW
Netswimmer
Per Zufall bin ich auf diese kleine, aber dennoch sehr informative FAQ gestoßen: http://jeroen.vangelderen.org/stuff/Little_UFS2_FAQ.txt
CW
CW
UFS2-MiniFAQ
- Ersteller CW
- Erstellt am
asg
push it, don´t hype
Ich meinte:
http://www.bsdforen.de/forums/showthread.php?s=&threadid=892&highlight=snapshot
Hier nochmal die Erklärung:
UFS2 & Erklärung Dateisystem (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
http://www.bsdforen.de/forums/showthread.php?s=&threadid=892&highlight=snapshot
Hier nochmal die Erklärung:
UFS2 & Erklärung Dateisystem (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