UFS vs. EXT2/3 NTFS Reiser

vxk

Well-Known Member
Gibt es irgendwo einen Vergleich bezueglich der Sicherheit (Datenverlust bei Plattendefekt, Stromausfall etc.) der verscheidenen Dateisysteme. Nochmal: mich intersiert nur die Sicherheit bezueglich Datenverlust, nicht die Performance und auch nicht die SIcherheit/Unsicherheit falscher Rechtvergabe->Hacker->Viren-Usw.
Hat irgendjemand persoenliche Erfahrungen gesammelt ?

P.S.: das "NTFS" hab ich nur der Form halber in den Betreff geschrieben. :)
VXK
 
Von so einer Aufstellung wüsste ich nichts, meiner Erfahrung nach ist ReiserFS (4) allerdings nicht zu empfehlen. Bei jedem Crash "vergisst" oder zerhäckselt es irgendwie Daten, dass ist in meinen Augen nicht gerade ein Argument für es. Gerade weil es (angeblich) ein Journal führt.
Aber wie gesagt, dass ist eine Einzelerfahrung und muss nicht durchgäng so sein!
 
Danke fuer deinen Link, nur der bringt mich nicht wirklich weiter...
Vieleicht könne hier n paar leute noch ihre persoenlichen Erfahrungen posten...
 
Hat hier nicht jemand vor ein paar Tagen den Link zum einem Paper von McKusick, et al. mit Thema Softupdates vs. Journaling gepostet?

Wenn du maximale Sicherheit willst, nimm UFS(2), ohne Softupdates, und schalte bei IDE den Cache aus.
Das ist zwar unglaublich langsam, aber sehr sicher ;)
 
ext2 unter *BSD hat imho genau zwei Daseinsberechtigungen:
1) Wenn man auf little und big endian Prozessoren auf das gleiche Dateisystem zugreifen will, geht das mit ext2, da es immer little endian zum Abspeichern der Daten verwendet
2) Zum Austausch von Daten mit Linux.
3) Als Spielwiese
 
little und big endian !?!?

wageck said:
was ist mit und big endian Prozessoren gemeint ?

Hm gute Frage !

Ich rate mal ins Blaue, daß es dabei um den Chipset auf der HD geht, welche sich um den schreib-/lesezugirff kuemmern... hm aber ich frag lieber mals dass Publikum...
hoffentlich habe ich es jetzt nicht zu sehr beinflusst.... :D
 
Schalte wc bei ATA ab unter UFS2, sonst fliegt die Kuh davon.
Im schlimmsten Fall sollten, bei UFS2+snapshots, die Daten der letzten 30 Sekunden nicht geschrieben werden.
Dafür ist aber für die Konsistenz des FS gesorgt.
Siehe auch:
http://www.bsdforen.de/forums/showthread.php?s=&threadid=892&highlight=snapshot

Code:
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:
[url]http://www.mckusick.com/softdep/index.html[/url]
 
ReiserFS: Spielwiese
NTFS: Genau :rolleyes:
ext2/3: 100 days since last filesystem check, fsck forced :rolleyes:

Das grosse Problem beim ext2fs ist das asynchrone schreiben der Metadaten, das wurde gemacht, weils sonst schnarchlahm ist. Mit UFS+softdeps hast du das Problem nicht mehr. Allerdings musst du sicherstellen, dass die Hardware zwischendrin nicht doch noch nen Cache einfuehrt. Bei ATA-Platten fuehrt das Abschalten des Write-Cache allerdings zu einem herben Performanzeinbruch. Bei SCSI ist der ueberlicherweise weniger ausgepraegt.

Zu den restlichen FS: Klick dich mal durch diesen Thread
http://leaf.dragonflybsd.org/mailarchive/users/2005-03/msg00674.html
 
ist doch ziemlich eingeschränt empfehlenswert softupdates zu verwenden wenn man es tatsächlich nur verwenden kann bzw. es nur richtig funktioniert wenn man seine ide platte zwingt extrem langsam zu arbeiten...
das ist doch ziemlich albern...
und hört auf dauernt reiserFS mit reiser4 gleich zu setzen ;'(
naja meine meinung hab ich schon hier

http://www.bsdforen.de/showthread.php?p=77237#post77237

kund getan...

ich schätze mal gerade die vorurteile gegen reiser4 kommen daher das suse und die darpa dieses Projekt unterstützen, dass diese Idee aber ursprünglich von BSD ist weiß kein Mensch.

naja was soll ich mich uffregen :zitter:
 
dissent said:
[...]
ich schätze mal gerade die vorurteile gegen reiser4 kommen daher das suse und die darpa dieses Projekt unterstützen, dass diese Idee aber ursprünglich von BSD ist weiß kein Mensch.

naja was soll ich mich uffregen :zitter:

Links?
 
Oh man, das muss einem doch gesagt werden, dass Reiser4 ~ LFS! Warum haben sich die da nicht bitteschoen einen anderen Namen ausgedacht, sondern die "Versionsnummer" erhoeht?

Na egal, jedes FS, welches in Kinderschuhen steckt sollte man nicht weiterempfehlen/verwenden. Den Leuten, denen man das empfehlen koennte, die wissen da selbst besser bescheid.
 
MrFixit said:
ReiserFS: Spielwiese
NTFS: Genau :rolleyes:
ext2/3: 100 days since last filesystem check, fsck forced :rolleyes:

Das grosse Problem beim ext2fs ist das asynchrone schreiben der Metadaten, das wurde gemacht, weils sonst schnarchlahm ist. Mit UFS+softdeps hast du das Problem nicht mehr. Allerdings musst du sicherstellen, dass die Hardware zwischendrin nicht doch noch nen Cache einfuehrt. Bei ATA-Platten fuehrt das Abschalten des Write-Cache allerdings zu einem herben Performanzeinbruch. Bei SCSI ist der ueberlicherweise weniger ausgepraegt.

Zu den restlichen FS: Klick dich mal durch diesen Thread
http://leaf.dragonflybsd.org/mailarchive/users/2005-03/msg00674.html
Code:
test:~# tune2fs -c 0 -i 0 /dev/hda4
tune2fs 1.35 (28-Feb-2004)
Setting maximal mount count to -1
Setting interval between check 0 seconds
test:~#
Und es findet kein: "100 days since last filesystem check, fsck forced" statt.
Ist selbstverständlich nur bei ext3 zu empfehlen.
 
Back
Top