Re: dateisystem

On 1999-09-07 13:51 +0200, Alexander Langer <alex(at)cichlids.com> wrote:
> > Nein. Ein "mv" innerhalb der Partition dauert jenachdem ob "softupdates"
> > im Kernel freigegeben sind (aus Lizenzgründen muß man das selber im
> > Kernel-Config-File machen und den Kernel neu bauen). Mit Soft Updates kann
> > man tausende von Dateien pro Sekunde innerhalb einer Partition verschieben,
> > ohne maximal 100 pro Sekunde (geschätzt).
>
> Was ist softupdates eigetnlich genau, was bringt es und wieso
> lizenz-gruende?

Es gibt Probleme mit dem FSCK nach einem Crash, wenn man nicht mehr
rekonstruieren kann, in welcher Reihenfolge bestimmte Operationen
Änderungen am File-System ausgelöst worden sind. Der schlimmste
Fall ist, daß Sektoren "indirekte Blocks" (also Zeiger auf Sektoren
für lange Dateien, wo diese Informationen nicht in die Inode paßt)
enthalten sollen, aber Wirklichkeit ein Binary oder andere "zufällig"
Daten enthalten. Das kann z.B. passieren, wenn eine große Datei neu
angelegt wird und dabei der Directory-Eintrag und die Inode vor den
indirekten Blocks geschrieben wird (und letztere dann bei einem Crash
evt. gar nicht mehr ...) Es kann leicht zu Situationen kommen, wo die
gleichen Blocks angeblich zu einem Directory und zu einer normalen
Datei gehören, es können die indirekten Blocks eines großen
Directories betroffen sein, etc. In so einem Fall würde der FSCK
letztendlich alle Dateien auf der Platte "sicherheitshalber" Löschen,
weil er bei keiner sicher sein kann, ob sie noch konsistent und gültig
ist ;-)
Schlimm genug ist aber, z.B. für Batch-Systeme oft, schon, wenn die
Reihenfolge von "rename" und "unlink" nach einem Crash nicht mehr im
File-System (auf Platte) besteht, weil nur ein Teil der Meta-Information
(in der falschen Reihenfolge) auf die Platte übertragen wurde. Das kann
zu völligem Datenverlust beim Wiederanlauf eines solchen Systems nach
einem Crash führen.

Aus diesem Grunde hat man im BSD File-System traditionell beim Schreiben
von Daten, Directory-Einträgen und Inodes bestimmte Reihenfolgen
eingehalten (vereinfacht gesagt: Die Daten-Sektoren dürfen erst dann
einer neuen Datei gegeben werden, wenn sichergestellt ist, daß AUF
DER PLATTE keine alten Referenzen mehr darauf betsehen. Das limitiert
z.B. die Rate von Datei-Anlegen und -Löschen auf einige 10 Dateien
pro Sekunde. Linux ignoriert diese "Kausalitäts"-forderung komplett,
man hatte zu Beginn (Minix) nicht den Anspruch dagegen gechützt zu sein
und später war das System dann ja berühmt für die Geschwindigkeit,
mit der es Dateien löscht, da wollte das wohl auch niemand mehr ändern ;-)

Das Ziel sollte also sein, daß der Platten-Kopf nicht ständig zwischen
Inode-, Directory- und Daten-Sektoren wechselt, um sie in "sicherer" Weise
nacheinander zu aktualisieren, sondern so viele Inode-, Directory und Daten-
Manipulationen wie möglich im RAM gesammelt werden, und dann für zig
oder hunderte Dateien in einer Schreiboperation auf die Platte übertragen
werden. Aber OHNE daß dabei jemals inkonsistente Informationen auf der
Platte sind, die den FSCK verzweifeln lassen.

Soft-Updates bringt ein Transaktions-System in den Kernel, das für jedes
Datei-Anlegen oder -Löschen prüft, ob bei einem Crash im Augenblick
ein inkonsistenter Zustand auf der Platte sein könnte. Wenn ja, dann
wird dafür gesorgt, daß genau die notwendige "Meta-Information" auf die
platte geschrieben wird, die wieder eine eindeutige Lage schafft (also den
FSCK in die Lage versetzen würde, richtig aufzuräumen). Technisch ist
das so gelöst, daß im Buffer-Cache zu einem Disk-Block mehrere Versionen
stehen können, die die Situation jeweils nach bestimmten File-System-
Operationen wiedergeben. Oft wird dann eine "Zwischenversion" des Blocks
auf die Platte geschrieben (d.h. die letzten Daten im Buffer-Cache würden
zu einem inkonsistenten Zustand auf der Platte führen, deshalb werden die
letzten Modifikationen nicht mit herausgeschrieben; das spart aber im Ergebnis
sehr viele Schreib-Operationen!).

Andere File-Systeme benutzen zum Teil einen "Log" (z.B. das "Journaled
File System" im AIX), in dem alle Änderungen an den Meta-Informationen
in ihrer Reihenfolge eingetragen werden, auch wenn die zugerörigen Blocks
mit Daten noch nicht auf die Platte gegangen sind. Der FSCK kann dann leicht
sehen, welcher Zustand vor einem Crash bestand (und wirft dabei oft die
Änderungen von zig Sekunden vor dem Crash konsistent weg, was ziemlich
verwirrend sein kann, wenn man eine "Recovery"-Datei zum Wiederaufsetzen
eines Batch-Jobs nach einem Neu-Start "naiv" alle paar Sekunden erzeugt ;-)

Das Soft-Updates Konzept führt letztendlich zum gleichen Ergebnis wie
der Transaktions-Log im JFS: Es gibt keine Probleme bei unvollständig
ausgeführten Veränderungen im Datei-System, weil zwar so viele wie
möglich nur im Buffer-Cache (also im RAM) ausgeführt werden, aber wenn
Daten dann doch auf die Platte geschrieben werden, dann für viele Dateien
auf einmal in optimaler Reihenfolge und trotzdem garantiert ohne daß es zu
widersprüchlichen Zuständen kommt, die der FSCK nicht auflösen könnte.

> Von wem istn das?

Der Code stammt von Kirk McKusick, dem Chef-Architekten von BSD-4.3 und
einem der prominentesten BSD-Entwickler. Auch am BSD Fast File System
(mit den heute für normal gehaltenen Eigenschaften wie: muß nicht
defragmentiert werden, erlaubt Symbolische Links und Datei-Namen bis 255
Zeichen Länge, das gleichzeitig aktuelle System V.3 hatte von Hause aus
ein Limit von 14 Zeichen, und wurde nach wochenlanger Benutzung langsam)
hat er maßgeblich mitgearbeitet.

Er lebt davon zu beraten, and der Universität Berkeley Kurse zu halten und
Software zu entwickeln. Er hat Soft-Updates entwickelt und an gibt Lizenzen
an Firmen, die es in ihre Produkte aufnehmen wollen (z.B. für Embedded
Control oder Black-Box Web- und INTRANET-Server). Daher verlangt er, daß man
eine lizenz bei ihm kauft, wenn man seinen Code in ein Produkt integriert,
nicht aber, wenn man die frei verfügbaren Sourcen in einem Projekt wie
z.B. FreeBSD verwendet.

Man hat sich darauf geeinigt, daß der Code im FreeBSD enthalten ist, aber
man durch eine etwas komplizierte Prozedur bei der man über die Lizenz-
Bedingungen stolpert, erst den Code in den Kernel hineinkompiliert bekommt.

Siehe dazu: /sys/contrib/softupdates/README, wobei aber zwischenzeitlich
noch einige Verbesserungen vorgenommen worden sind.

> Ist das stabil?

Es wird auf einer großen Zahl von Servern im INTERNET benutzt. Ich selber
habe es auf SMP-Systemen seit langem problemlos im Einsatz. Es bringt auf
Rechnern die z.B. Mail oder News verwalten (oder ein CVS-Repository) eine
ganz erhebliche Verbesserung des Durchsatzes, ohne daß man das Risiko
eingeht nach einem eventuellen Crash (oder Strom-Ausfall) das File-System
in einem völlig korrupten Zustand zu haben ...

Früher habe ich für manche Zwecke (Daten, die man leicht wieder
rekonstruieren kann) einen "asnchronen" Mount verwendet, der auch die
Reihenfolge von Datei-System-Operationen optimiert, ohne aber irgendeine
Sicherheit im Falle eines Crashs zu geben. Mit Soft-Updates ist man in
der Regel schneller (!), und das ohne Risiko.

Gruß, STefan

To Unsubscribe: send mail to majordomo(at)de.FreeBSD.org
with "unsubscribe de-bsd-questions" in the body of the message
Received on Sat 11 Sep 1999 - 12:45:42 CEST