makro-journaling - war: Re: [linux-l] lokales Netz - NFS oder Samba?

[Peter Ross]

Hallo Frank,

On Tue, 17 Apr 2007, Frank Reker wrote:

> Am Mon 16. Apr 2007 21:35 +1000 schrieb Peter Ross:
> >Stelle Dir vor, Du hast ein Apachelog, welches einmal geoeffnet wird, und 
> >dann schreibt Apache tagelang Megabyte fuer Megabyte - ohne sync (weil Du 
> >nicht moechtest, dass das System nur deswegen in die Knie geht, weil die 
> >Accesslogs immer sofort geschrieben werden muessen)
> 
> logfiles werden in aller regel im append-mode geoeffnet. da hierbei nichts
> ueberschrieben werden kann, ergibt sich das problem nicht.
> macro-journaling (nennen wir es mal so) sollte nur aktiviert werden,
> wenn die datei im read-write (O_RDWR) oder write-only (O_WRONLY) mode
> geoeffnet wurde, und zwar ohne die flags O_APPEND und O_SYNC. ob 
> macro-journaling nur bei bereits bestehenden dateien aktiviert werden
> sollte oder auch dann wenn die datei neu erzeugt wird, ist 
> ansichtssache.

Das ist Sache der Anwendung, der Kernel kennt keine "Ansicht", kann 
nicht raten, was die App moechte.

Wenn Du moechtest, dass entweder ganz oder gar nicht geschrieben wird, 
gibt es den bereits genannten Weg ueber temporaeres File, welches beim 
Schliessen das originale ersetzt.

Wie es z.B. vi tut, inklusive der angebotenen Recoveryoption (da hast Du 
beides - Du kannst Aenderungen etfernen oder akzeptieren!)

Wozu also den Kernel um irgendetwas erweitern, wofuer es keine 
Notwendigkeit gibt? Nur, weil eine App zu daemlich ist, die Moeglchkeiten 
zu nutzen?

Wenn andersrum Du Deinen Wunsch zum Default machst, wuerden alle 
Anwendungen, die konstant etwas schreiben wollen, aber nicht unbedingt die 
"Hochsicherheit" des Sync brauchen, gezwungen, das zu verwenden - und das 
bremst das I/O-System und damit alle Anwendungen.

Will ich wirklich nicht.

> >Nein, so ab und an wuerde das Betriebssystem schreiben, und Journaling 
> >der Daten ist extra dafuer entwickelt worden, damit das System wirklich 
> >moeglichst wenig vergisst.
> 
> nein. dafuer nicht. sondern damit bei einem absturz das dateisystem
> konsistent bleibt. stell dir vor, du willst ne datei anlegen. das fs
> alloziiert ne inode, und bevor der dazugehoerige verzeichniseintrag
> generiert werden kann sturzt dein system ab. es wuerde also eine
> unverlinkte inode uebrigbleiben. aehnliche situationen koennten sogar
> das ganze fs unbrauchbar machen. um das zu verhindern werden alle
> dateisystemoperationen in mini-transaktionen verpackt und in ein
> repository (journal) zwischen-geschrieben. dadurch wird garantiert,
> dass eine operation ganz oder gar nicht ausgefuehrt wird, aber niemals
> halb.

Das ist Metadatenjournaling, ja. Aber kein Widerspruch zu meinem Satz:

> des weiteren gibt es auch data-journaling - also journaling des inhalts 
> der datei.

Genau davon sprach ich: "Journaling der Daten"

Das ist nicht fuer die Konsistenz der Daten notwendig, das hat genau den 
Zweck, den ich oben beschrieb.

> eine transaktion ist hierbei aber immer nur _eine_ write-instruktion. 
> und das wuerd ich gern erweitert wissen.

Erweitern ist etwas anderes als Aendern des Verhaltens von Filesystemen.

Ich habe mich mit reiserfs nie ordentlich beschaeftigt.. aber war da nicht 
was in der Hinsicht?

(Jetzt bin ich es, der "Halbwissen" in den Raum wirft,;-) Bitte 
widersprecht mir, wenn reiserfs nichts damit zu tun hat)

Gruss
Peter