Re: Filesysteme

From: Stefan Bethke <stefan(at)promo.de>
Date: Wed, 17 Jun 1998 11:04:33 +0200

--On Mit, 17. Jun 1998 7:48 Uhr +0200 Gerd Bitzer
<gbitzer(at)motor-presse-stuttgart.de> wrote:

> Hallo Allerseits,
>
> mich beschäftigt da eine Frage, aus der sich hier aber kein
> Glaubenskrieg entwickeln soll, und zwar die Effizienz/Performance vom
> FreeBSD Filesystem.

Ich hoffe, das beachten auch die anderen!

> Ich hab auf meiner Kiste ein Linux mit Kernel 2.0.34 und Ext2 Filesystem
> und das FreeBSD 2.2.5 mit dem BSD (?) Filesystem, installiert auf 2

FFS, Fast File System.

> verschiedenen, Platten (in Etwa gleichwertig, vom selben Hersteller, am
> selben SCSI Adapter, im selben PC), auch in Etwa gleich viele Daten.
> Das FreeBSD Filesystem kommt mir weniger effizient vor. Lasse ich z.B.
> einen 'find' auf eine Datei laufen, die bei beiden Systemen in Etwa
> gleich tief im Filesystem ist, läuft der 'find' bei FreeBSD wesentlich
> länger, ist auch wesentlich zugriffsintensiver (was sich ja direkt aus
> der Geräuschentwicklung der Kopfpositioniervorgänge hören läßt).

Deine Beobachtung ist richtig, Deine Vermutung nicht wirklich.

> 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?

> 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?

> 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.

Die Option "async" schaltet die synchronen Writes auf die Platte aus, und
überläßt es dem Buffer-Cache, die Blöcke irgendwann mal zu schreiben.

Kann der Kernel bei einem Problem nicht mehr alle Blöcke auf die Platte
schreiben, gibt es die nicht eben unwahrscheinliche Möglichkeit, daß fsck
die dadurch entstandenen Probleme nicht mehr beheben kann (prinzipiell
unmöglich, nicht, weil fsck zu doof wäre).

Das kann bedeuten, daß Du nach einem Absturz das Filesystem neu aufsetzen
mußt; mit etwas Glück kannst Du noch einige Daten retten.

Trotz der gängigen Erfahrung "mein Linux ist mir schon hundertmal
abgestürzt, und nie hatte ich Probleme" ist dies ein nicht
wegzudiskutierender Fakt; nur weil viele Leute auf ihren wenig belasteten
Heimcomputern Glück hatten, heißt das nicht, daß es nie auftritt, noch nich
mal, daß es selten auftritt (Newsserver).

Grundsätzlich kann man also nur davon abraten, irgendein Filesystem, daß
wichtiger als /tmp ist, async zu mounten. Wenn Du ein stark belastetes
Filesystem hast (/var/spool/news), hilft es, wenn Du die Option noatime
verwendest; so werden die sonst notwendigen Updates auf viele inodes
vermieden (siehe mount(8)).

Eine neue Entwicklung sind die sog. "soft updates". Leider sind sie nicht
Standardbestandteil von FreeBSD 2.2.6, und werden es wohl auch nicht von 3.0
sein, sie lassen sich aber selbst nachrüsten.

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.

Leider (für uns Anwender) hat der Autor, Marshall Kirk McCusick, ein recht
restriktives Copyright auf den Code gelegt, der die übliche Integration in
den Kernel verbietet. Für die Nutzung auf dem eigenen System kann man den
Code aber selbst einbinden.

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 - 11:05:11 CEST

search this site