[linux-l] Neues Root-Dateisystem

[Peter Ross]

On Thu, 6 Jul 2006, Volker Grabsch wrote:

> Das ist ein Performance-Argument.

Und auch ext3 kennt das. Dies hier ist aus der manpage fuer tune2fs:

- journal_data

When the filesystem is mounted with journalling enabled, all data (not 
just metadata) is committed into the journal prior to being written into 
the main filesystem.

- journal_data_ordered

When the filesystem is mounted with journalling enabled, all data is 
forced directly out to the main file system prior to its metadata being 
commutted to the journal.

- journal_data_writeback

When the filesystem is mounted with journalling enabled, data may be 
written into the main filesystem after its metadata has been commutted to 
the journal.  This may increase throughput, however, it may allow old data 
to appear in files after a crash and journal recovery.

Und nicht nur ext3. Auch das darunterliegende IO. Hast Du z.B. den 
Plattencache ausgeschaltet? ;-) Das bremst eine Platte ganz merklich.

BTW: SuSEs 8.2 mkfs.xfs manpage nennt beim ersten Erwaehnen des Logs 
dieses "The metadata log", ist also praezise.

Es kommt doch bei vielen Sachen drauf an, wie wichtig Konsistenz ist, wie 
wichtig Metadaten und Daten.

Ein heiles Filesystem oder eines, welches im Background gecheckt wird (wie 
unter FreeBSD), verkuerzt einen Bootprozess erheblich. Dafuer muessen die 
Metadaten konsistent sein.

Und mein RAID hilft mir, keinerlei Datenverluste zu haben, weil eine 
Platte kaputt geht.

Das ist fuer mich wirklich wichtig.

Nun betreue ich eine rund um die Uhr laufende Anwendung. Das sie immer 
oben ist, und keine Daten verloren gehen, ist wichtig.

Aber wenn es denn mal crasht (in der Regel durch Java+Applikation, nicht 
durch OS+Hardware), wird wieder restartet. Aergerlich, aber nicht zu 
aendern (klar, dass daran gearbeitet wird, dass es nicht mehr vorkommt)

Anyway, wenn das OS crasht und das letzte File, was gerade vom Anwender in 
den Datenstore geladen wurde, noch nicht geschrieben ist, ist das zwar 
auch nicht gut, aber fuer den Anwender ersichtlich - es hat geknallt, der 
Server ist weg, "connection refused" - nun, ich muss mich wieder einloggen 
und noch mal hochladen. (Ich rede hier nicht vom taeglichen Crash, aber es 
kann mal vorkommen, die Applikation ist zumeist einige Wochen 
unterbrechungsfrei online).

Das rechtfertigt durchaus, eine Option zu verwenden, die 
RAID+Metadatajournal beinhaltet, aber kein Datenjournal, wenn ich an die 
Grenzen der verfuegbaren IO-Bandbreite stosse.

Bei der Datenbank dagegen haette ich gern alle Daten wirklich 
geschrieben, sonst habe ich unter Umstaenden eine Datenbank, die korrupt 
ist, und nicht wieder "hochkommt".

Und bei meinem Rechner zuhause ist es ganz nett, 
UFS2+Softupdates+Backgroundcheck zu haben, damit mein Rechner schnell 
wieder hochkommt, mir auch bedenkenlos ein sofortiges Stromabschalten 
erlauben kann, ohne Angst vor defektem Filesystem zu haben, aber mit 
meinen paar Gigabyte waere auch ein UFS1 ohne das wahrscheinlich okay.

Da brauche ich mit Sicherheit kein Datenjournal, schon ein robustes 
simples Filesystem reicht aus.

Fuer ein Read-Only-System gaaanz sicher.

Wenn Du dagegen ein Flashdevice hast, bei dem die Anzahl der 
Schreibzugriffe waehrend der Lebenszeit begrenzt ist, sehen die 
Anforderungen ganz anders aus.

Die o.g. unterschiedlichen Anforderung je Anwendung koennen uebrigens auch 
eine sehr spezielle Partitionierung rechtfertigen. Z.B. andere 
Journaloptionen fuer /var/db, wenn es ein DB-Server ist.

Ich habe mir angewoehnt, Partitionen nicht direkt an eine Stelle zu 
mounten, sondern unter /mnt/vol1, und dann Symlinks dahin zu legen. Das 
macht mich flexibler, um auf die Anforderungen des taeglichen Betreibs zu 
regieren.

Gruss
Peter