Freebsd "sicheres" Filesystem?

  • Thread starter Thread starter oliver_herold
  • Start date Start date
O

oliver_herold

Guest
Moin,

seltsamer Titel aber mir gehts ums Filesystem. Hatte mich mal ein wenig informiert - wenn ich es richtig verstanden habe nutzt Freebsd UFS2, ein Aufsatz/eine Erweiterung zu UFS. UFS ist kein journaling Filesystem, einige finden das hier im Forum auch nicht so "toll" ;), andere reden von soft updates.
Im Zusammenhang mit soft updates kam dann noch der Einwand von der Unzulänglichkeit des write caches bei IDE Platten.

Ok hier meine Voraussetzungen,

-Freebsd als ausschließliches Desktopsystem
-Intel P640 + i865, 1Gb Speicher, Samsung+Maxtor Platte

Der Grund für die Frage, -> reset :rolleyes: mit schlimmen "Verwüstungen" in der Dateistruktur die eine Neuinstallation unumgänglich machte.

-werden soft updates automatisch genutzt oder muß man dieses Feature erst aktivieren?
-muß man/soll man den write cache deaktivieren bei IDE Platten?
-falls ja, wie groß ist der Performance-Entzug?

Ok es ist mir schon klar das man Backups etc. macht und das irgendwelche anderen Filesystem auch keine Wunder wirken können. Aber mich interessiert halt wie ich das bestmögliche "herausholen" kann - sprich falls mal ein crash irgendeiner Art auftritt :)


gruß Oliver
 
Ja, softupdates werden automatisch aktiviert (ausser auf /, aber auch da nutze ich es).
Auch ein reset macht meinem FS nichts aus, startet eben ein bgfsck wenn die Kiste wieder hochfährt.
 
Wenn du _wesentlich_ sicherer sein willst musst du bei IDE den Write Cache abschalten. Aber die performance einbußen sind imo so dramatisch, dass dies nicht praktikabel ist.

@asg: Wenn du IDE benutzt hast du bisher glück gehabt. Es kann durchaus passieren, dass etwas gewaltig schief geht. Die Konsistenz von soft-updates setzt "nicht lügende" Platten voraus. (Ich bin mir nicht sicher, aber ich glaube auch Journaling kann in diese Falle tappen).

Gruss
Male
P.S. Selbst mit deaktiviertem WriteCache kann es zu Inkonsistenzen kommen, allerdings dann sehr unwahrscheinlich :)
 
Soft-updates sind eigentlich zeit-verzögertes Journaling. Das bringt den Vorteil das rekursive Dateioperationen (deutlich) schneller als bei syncronem Journaling gehandhabt werden können. Der Nachteil ist, das neue Dateien bei einem Absturz "verschwinden". Der Vorteil ist, das du gelöschte Dateien retten kannst indem du den Stecker ziehst.
 
Das "Journal" ist im Ram!
Und vonwegen Dateien retten musst du extrem viel glück haben. Von so einer bescheurten Benutzung on Softupdates hab ich noch nie gehört, LOL.
 
@tib
Wenn dann startet ein bgfsck und der stört ja nicht weiter. Wenn wirklich ein fsck nötig war, dann sicher deshalb, weil auf / kein softupdates aktivert war (per default wird es dort bei der Installation nicht aktiviert).
 
tib, ich mache sehr viel mit QEMU, und bisher ist FreeBSD darin immer sauber heruntergefahren.

Für / gibt es immer einen foreground fsck afaik. Das hat mit soft-updates erstmal nichts zu tun. Und ich empfinde einen bgfsck schon als störend, das zieht ganz schön leistung ab. Das / per default keine soft-updates hat ist schon ok, schließlich braucht man auf / auch keine performance, gell? :)
 
Also kann ich im Prinzip alles so lassen wie es ist, Probleme oder "User-Ausfälle" ;) weitesgehende vermeiden und oft Backups fahren?! Danke nochmal für die zahlreichen Infos.

gruß Oliver
 
Maledictus said:
Das / per default keine soft-updates hat ist schon ok, schließlich braucht man auf / auch keine performance, gell? :)
Jein, man braucht keine Schreib-Performanz und beim Lesen ist Softupdates ueberhaupt nicht beteiligt. Ausserdem ist / ja ueblicherweise nicht groesser als max. 512MB, und da ist ein fsck ja ruckzuck fertig.

Das mit dem "Journal im RAM" was hier im Thread aufkam ist jedoch voellig daneben. Es wird keinerlei Journal gefuehrt, es werden nur Metadaten-Updates umsortiert, so dass sie performanter geschrieben werden koennen, und so dass garantiert werden kann, dass fsck wieder einen konsistenten Zustand der Metadaten (sic!) herstellen kann. (sorry, fuer die vielen "dass").

In einer "perfekten Welt" ist SU "besser" als Journals, weil es einfach mal schneller ist. Leider gibt es Ausfaelle, v.a. bei Consumer-Hardware, und deshalb ist Backup auch mit UFS nicht vermeidbar. Wer wirklich ein JFS braucht, der muss leider wo anders hingehen.
 
Back
Top