Re: Filesysteme

Hallo

Stefan Bethke wrote:

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

Deswegen hab ich es ja ganz oben hin geschrieben.

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

Beim Boot zeigt (fsck ?) an, wie hoch der Fragmentierungsgrad der Files ist. Und
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.

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

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

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

Ist klar.

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

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

Hört sich interessant an. Gibt es denn irgendwo Infos, wie das FFS überhaupt
aufgebaut ist ?

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

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

>
>
> 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 - 13:47:14 CEST