Re: Filesysteme

From: Stefan Bethke <stefan(at)promo.de>
Date: Wed, 17 Jun 1998 15:30:29 +0200

--On Mit, 17. Jun 1998 13:46 Uhr +0200 Gerd Bitzer
<gbitzer(at)motor-presse-stuttgart.de> wrote:
> Stefan Bethke wrote:
>
> > --On Mit, 17. Jun 1998 7:48 Uhr +0200 Gerd Bitzer
> > <gbitzer(at)motor-presse-stuttgart.de> wrote:
> > > Auch
> > > scheint mir das BSD Filesystem stärker zu fragmentieren, wenn ich so
> die
> > > Zahlen die beim Booten auftauchen vergleiche (obwohl ich eher bei dem
> > > Linux schon mehr auf der Platte gemacht hab, also in Form von
> > > Softwareinstallation und Deinstallation, File-IO etc.).
> >
> > ??? Welche Zahlen?
>
> Beim Boot zeigt (fsck ?) an, wie hoch der Fragmentierungsgrad der Files
> ist. Und

OK.

> da hab ich in meinem Environment unter Linux einen geringeren
> Fragmentierungsgrad (bei ungefähr gleicher Anzahl Files/Datenvolumen) als
> bei
> FreeBSD, obwohl ich unter Linux eher schon mehr auf dem Filesystem
> gearbeitet
> habe, als unter FreeBSD. Die Fragmentierung unter FreeBSD also geriinger
> sein
> müßte.

Und? Ich weiß nicht genau, was da überhaupt ausgerechnet wird, und das wird
ggf. auch noch unterschiedlich zwischen ext2fs und ffs sein.
"Fragmentierungsgrad" ist kein Wert an sich; interessant ist, wie sich die
Plazierung von Blöcken auf die Zugriffszeiten auswirkt. Keine Ahnung, ob es
dazu irgendwelche Untersuchungen gibt...

> > > Ach ja, die
> > > unwichtigeren Slices hab ich beim FreeBSD async, noatime gemounted,
> was
> > > ja aber bei der oben genannten Sache mit dem 'find' wohl nicht zum
> > > Tragen kommen dürfte.
> >
> > Wieso sollte das keine Rolle spielen?
>
> Das async wird sich ja IMHO bloß auf Schreibvorgänge beziehen, während das
> noatime ja auch für Lesezugriffe relevant sein wird.

Nein. Da die Access Time im inode verändert wird, wenn Du Dir ein
Verzeichnis anschaust, muß der indoe auch zurückgeschrieben werden. Ich hab
mir das nicht im Detail angeschaut, aber "worst case" wäre, für jeden
Eintrag die Access Time zu aktualisieren; also ein Schreibzugriff.

> > > Die Frage die sich mir da stellt ist natürlich, ist das FreeBSD
> > > Filesystem (oder sein Caching oder was weiß ich) wirklich weniger
> > > effizient wie das Ext2, gibt es da seitnes der Entwickler Erkenntnisse
> > > oder Aussagen, sind da zukünftig Entwicklungen zu erwarten ?
> >
> > Es ist ganz einfach: Linux mounted per default "async", unter FreeBSD
> ist es
> > nicht per default aktiv.
> >
> > Warum? Wie Dir Terry Lambert gerne im Detail auseinandersetzen wird :-),
> ist
> > die Reparatur (roll-back) nach einem Crash nur möglich, wenn
> > Meta-Daten-Updates in der richtigen Reihenfolge auf die Platte
> geschrieben
> > werden.
>
> Ja, das kann ich mir schon vorstellen. Das Thema Journaling Filesysteme
> wie es
> sie bei 'Not Today' oder auch bei professionellen UXen gibt, zielt ja auch
> in
> die Richtung, den fsck (als Vorgang) sauber definiert ablaufen zu lassen,
> also
> den Rollback der unterbrochenen Transaktion möglich zu machen.

Das hat erstmal nichts mit "Journaling File System" oder anderen
Shadow-Page-Systemen zu tun; das Thema "Konsistenz" ist generell für
Filesysteme wichtig.

> > Das kann bedeuten, daß Du nach einem Absturz das Filesystem neu
> aufsetzen
> > mußt; mit etwas Glück kannst Du noch einige Daten retten.
>
> Hmm, ich hatte mit nicht journalenden Filesystemen schon dann + wann
> Abstürze,
> da waren eigentlich nur einzelne Files zerballert, aber nie komplette
> Filesysteme. Bis hin zu manuellen fsck's gingen die Beschädigungen, aber
> nie
> komplette zerballerte Filesysteme.

Glück gehabt.

> > Soft Updates sortieren die Updates so, daß sie verzögert ausgeführt
> werden
> > können, aber die Konsistenz des Filesystems bei nicht-Zurückschreiben
> > trotzdem erhalten bleibt. Dadurch wird eine Performance wie mit "async"
> > erreicht, aber ohne die Nachteile.
>
> Hört sich interessant an. Gibt es denn irgendwo Infos, wie das FFS
> überhaupt
> aufgebaut ist ?

/usr/src/sys/ffs :-)

McKusic et al., "Design and Implementation of the 4.4BSD Operating System",
in jeder gut sortierten Buchhandlung.

Speziell zu "Soft Updates":
http://www.ece.cmu.edu/~ganger/papers/CSE-TR-254-95/

[ Soft Updates ]

> Wird sich aber wohl eher für höherbelastete File/News Server anbieten, auf
> Workstations die traditionell nicht so viele Schreibzugriffe haben,
> weniger
> stark auswirken

Kommt 'drauf an. Selbst auf meinem 486 ist ein make world ziemlich disk
bound; mit Soft Updates sollte das eine ganze Menge bringen, ohne die
Sicherheit zu verlieren (ich habe im Moment /usr/obj async gemounted, und
bei diversen Crashes ist mir das auch regelmäßig weggeflogen).

Stefan

--
Stefan Bethke
Promo Datentechnik      |  Tel. +49-40-851744-18
+ Systemberatung GmbH   |  Fax. +49-40-851744-44
Eduardstrasse 46-48     |  e-mail: stefan(at)Promo.DE
D-20257 Hamburg         |  http://www.Promo.DE/
Received on Wed 17 Jun 1998 - 15:31:08 CEST

search this site