asynchrone Metadaten (Re: VMware)

Hai, Christian,

In <NDBBJMNNEPKCHPDOJAEBKEOKDKAA.christian(at)jacken.net>, Christian Jacken wrote:
> Hallo Martin Cracauer,
>
> seit den letzten Wochen befasse ich mich verstärkt mit FreeBSD und bin dabei
> auch auf Deine kurze Webpage gestoßen, wo Du die Risiken von klassischen
> UNIX-Filesystemen und die Vorteile vom native FreeBSD File System gegenüber
> ext2 beschreibst.

Na der Morgen faengt ja gut an :-)

> <Kleiner Auszug>
> The "meta-data" operations can cause you to lose your whole filesystem
> (partition) or they can delete or truncate files that just happened to be
> "neighbors" of the files you wrote.
> </Kleiner Auszug>
>
> Diese Infos haben in der Münchner Linux Mailing Liste für einige Polemik

Kann ich mir vorstellen. Sachlich kann man asynchrone Metadaten als
Default auf allen Usersystemen nicht verteidigen.

> gesorgt. Sogar Beiträge von Linus in der Newsgroup
> comp.os.linux.development.system wurden zitert. Hier hat Linus anscheinend
> ext2 standhaft verteidigt und gleichzeitig das FreeBSD-FS atackiert (Sein
> Fazit: Weniger Performance und dennoch nur Pseudo-Sicherheit).
> Teilweise wurden uebrigens von Linus Worte verwendet, die ich von ihm nicht
> erwartet hätte - ist das normal (vorausgesetzt es war wirklich Linus der da
> postete)?

Wenn Linus mal vernuenftig argumentiert, dann sagt er eine Sache, die
stimmt: Weil ext2fs keine Fragmente kennt, ist es unter gleichen
Mountoptions nicht so anfaellig fuer kaputte Metadaten. Das aendert
aber nichts an der Tatsache, dass das Risiko damit immer noch nicht
auf ein vernueftiges Mass reduziert wird. Von dem offensichtlichen
Nachteil, dass viele kleine Dateien dann massig Platz verschwenden
und/oder dass die Blockgroesse begrenzt ist, nicht zu reden. 4B
Bloecke sind im Zeitalter von CPUs mit teuren Functioncalls ein echter
Nachteil, weil zwar nicht jeder Block einen Systemcall braucht, aber
doch innerhalb des Kernels functioncalls. versuch mal, ein freeBSD mit
$KB Bloecken zu fahren.

Uebrigens empfiehlt selbst John Dyson, fuer Filesysteme mit extremen
Sicherheitsanforderungen beim FFS keine Fragmente zu verwenden (ist
eine newfs option).

Erwaehnenswert ist ueberigens auch, wieso das FreeBSD ext2fs bei
gleichen Optionen langsamer ist als ein ext2fs unter Linux: Weil Linux
die Reihenfolge der Bloecke, die rausgeschrieben werden,
ausschliesslich anhand der optimalen Reihenfolge fuer die
Verarbeitungsgeschwindigkeit der Platte festlegt. FreeBSD sorgt
wenigstens fuer wichtigstens-zuerst.

Ich bin auch nicht ganz willens, das ganze gross zu diskutieren: Ich
habe schon immer FreeBSD (vormals NetBSD) und Linux im Einsatz und
habe persoenlich zu oft erlebt, dass ein Linux nach einem Crash eben
nicht mehr sein Filesystem zurechtgebastelt bekam. Von dem Scherz des
haengenbleibenden fsck beim booten nicht zu reden. Sehr angenehm, weil
zumindest die Debian-1.3 Startprozedur nicht erlaubt, beim ablaufen
von /etc/rc* mit Control-C oder Control-\ Signale an den Prozess zu
senden (was FreeBSD dank Bruce Evans wunderbar kann, wenn nicht gerade
jemand pcvt sabotiert).

Solche Geschichten kann ich nicht beweisen und schon gar nicht
quantitativ bewerten. Fuer mich selber ist mein Eindruck ueber die
Zweckmaessigkeit von asynchronen Metadaten damit jedoch klar, und
damit auch ueber Leute, die dieselben heftig verteidigen. Linus ist
nun mal ein Coder (ein sehr guter natuerlich), aber eben nicht viel
mehr.

Und warum bruellen eingentlich alle Linuxer nach verbesserten
Filesystemen, wenn ext2fs so toll ist. Hast Du schon mal erlebt, was
passiert, wenn jemand nach gleichen Filesystemen auf freebsd-hackers
oder freebsd-fs fragt? Achselzucken. Wozu? Wenn schon, dann was
wirklich sicheres (siehe unten), aber die fuer Linux jetzt
diskutierten Loesungen sind eben nicht besser als ffs und softupdates.

Stichword Softupdates: FreeBSD hat seit 3.0 Softupdates. Softupdates
sind schon auf Rechnern mit 16 MB RAM ein Vorteil, ich glaube also
sagen zu duerfen, dass die Linuxer doch bitte schoen asynchron vs.
Softupdates betrachten moecgen und nicht asynchron gegen synchron. Die
Menge von Leuten, die darauf aus Lizenzrechtlichen, RAM oder
versiongruenden verzichten muessen, duerfte jetzt wohl klein genug
sein.

Alan Cox behauptet auch gerne, dass beim FFS nach einem Crash die
Metadaten in dem dann reparierten Stand auf alte oder falsche
Datenbloecke zeigen koennen. Diese Behauptung sollte man mal
ueberpruefen bzw. Kirk vortragen. Ich glaube eigentlich nicht, dass
das bei Softupdates noch passieren kann (falls es vorher passieren
konnte), aber Softupdates sind mir zu kompliziert, um das im Codepath
nachzulesen. Ist aber auf jeden Fall besser als Linux, wo die
Metadaten selbst zufaellig in der Gegend rumzeigen, eben auch auf
Datenbloecke, die ploetzlich als Metadaten intepretiert werden und
aehnliche Scherze (autsch).
 
> Doch zurück zum Thema, mit einem Zitat aus einer über die MLUG gelaufenen
> Mail (in diesem Zusammenhang fragte ich vor kurzem auch nach einem JFS für
> FreeBSD):
> > Merke: ein JFS/LFS stellt nicht die Integrität der Daten sicher, sondern
> > nur die der Metadaten, d.h. der Filesystemstruktur. D.h. bei einem Crash
> > ist das Dateisystem noch konsistent oder kann aufgrund des Transaction
> Logs
> > sehr schnell rekonstruiert werden (i.e. kein fsck im herkömmlichen Sinn).
> > Das heißt nicht, daß alle Nutzdaten nach einem Crash noch lesbar sind!

Es gibt alle moeglichen Filesysteme dieser Art. Alleine die
Formulierung "JFS/LFS" laesst darauf schliessen, dass sich hier jemand
aeussert, der nichts willens ist, sich mit technischen Details
auseinanderzusetzen. In einem echten LFS (so einem mit Garbage
Collector) ist tatsaechlich die Consistenz auch der Daten
sichergestellt. Andere haben einen Log, der einzig dazu dient, den
fsck zu vermeiden, obwohl sie ansonsten voellig normal sind.

Bevor man das klaeren kann, muss man erst mal fragen "Consistenz oder
Garantie der Daten auf dem letzten Stand"? Das ist ein grosser
Unterschied.

Wenn der systemcall (write fuer Nutzdaten, open/close/unlink fuer
metadaten) in die Applikation zurueckkehrt, soll dann die
Applikation sicher sein koennen, dass sie auch bei sofortigem Crash
genau die ben geschrieben Daten auf der Platte wiederfindet? Oder soll
"nur" sichergestellt sein, dass die Nutz/Metadaten immer einen Stand
gleicher Zeit (aber *nicht* unbedingt den neuesten) haben? Letzteres
ist das, was allgemein als "Konsistenz" bezeichnet wird und von den
meisten neuen Filesystemen forciert wird. Es ist aber eben nicht das,
was die Leute erwarten, die wollen eigentlich ersteres und wundern
sich ueber die timewarps (einmal um die Sonne und dann mit Schwung).

Softupdates haben mit LFS nix zu tun und stellen nur Consistenz von
Metadaten sicher (aber eben *nicht* aus dem letzten Stand aus
Applikationssicht).

Ich bin persoenlich froh, dass solche Leute sich bei Linux austoben
koennen, so haben wir wenigstens unsere Ruhe.

Um das klarzustellen: Fuer Daten, die *richtig* sein sollen (ich meine
so richtig richtig), ist das ganze Geraffe mit Virtual Memory,
Filesysteme, die Daten haeppchenweise speichern und erst recht ein
Write-Cache voellig ungeeignet. Fuer solche Scherze muss Du Dich
direkt mit der Platte (falls Du ueberhaupt eine benutzt) unterhalten,
und zwar mit einer, bei der der Cache strammsteht, wenn Du es von ihm
verlangst. Um das ganze mit einigermassen Performance hinzukriegen,
ist als allererstes ein voellig neues API fuer die Applikation noetig.
Vor allem muss die Applikation sagen koennen, ab wann sie die
Konsistenz oder spaetere Richtigkeit der gerade geschriebenen Daten
voraussetzt und/oder das OS muss der Applikation sagen, welche Daten
inzwischen sicher sind. Wenn Du das einfach fuer jeden write() einzeln
machen willst, katapultierst Du Dich ins PC/XT - Zeitalter zurueck. Du
waerst erstaunt, wie langsam ein Ninja-Macho Pentium sein wuerde, wenn
er bei jedem solchen Systemcall die Platte bemuechen wuerde, der
Platte verklickert, sie soll ihren eigenen Cache leeren und bitte eine
Bestaetigung zurueckgeben, dass das geklappt hat (am besten die
geschriebenen Bloecke als Pruefsumme PGP-Signiert mit einem Key pro
Platte, damit man hinterher den Hersteller verklagen kann, wenn nicht
das gleiche wieder rauskommt).

Seht euch mal "Gross"rechner oder auch nur ernsthaft
gedachten Datenbanken an, wie die an die Sache rangehen. Mit einfach
open() und dann Daten rein da ist das nix.

Martin

-- 
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
Martin Cracauer <cracauer@cons.org> http://www.cons.org/cracauer/
  Tel.: (private) +4940 5221829 Fax.: (private) +4940 5228536
To Unsubscribe: send mail to majordomo(at)de.FreeBSD.org
with "unsubscribe de-bsd-questions" in the body of the message