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

Frank Reker frank at reker.net
Mi Apr 18 01:24:36 CEST 2007


Hei Peter,

Am Tue 17. Apr 2007 10:02 +1000 schrieb Peter Ross:

>On Tue, 17 Apr 2007, Frank Reker wrote:
>
>> 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.

sprechen wir eigentlich die selbe sprache?
ich sag, dass ich fuer einen teilaspekt kein festgelegtes konzept
hab, da es fuer das eigentliche problem nicht relevant ist.
und du antwortest mir, dass der kernel nicht raten kann was
die app will - häähhh???
nichts fuer ungut, nur irgendwie komm ich mir grad auf den arm
genommen vor...


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

jetzt drehen wir uns im kreis.


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

wozu eigentlich druckertreiber schreiben, nur weil die app zu
daemlich ist, das selber zu machet?!



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

bei einem unix system (bei win uebrigens auch) wird nicht 
sichergestellt, dass irgendetwas geschrieben wird, nicht ehe ein
sync oder close aufruf erfolgt. selbst wenn ein write success
meldet, heisst das nicht, dass der write-vorgang auch wirklich
ausgefuehrt wird. wenn ein programm also sicherstellen will, das
die datei auch geschrieben wird, muss sie entweder ein sync() oder
ein close() aufrufen, oder die datei mit O_SYNC oeffnen.
das ist auch ohne makro-journaling schon so. ein makro-journaling
widerspricht also nicht der spezifikation. mit und ohne 
makro-journaling:
wird eine datei ordnungsgemaess geschlossen, also:
open ()
write ()
...
close ()
verhaelt sich das system gleich. wird aber das close() weggelassen,
dann handelt es sich entweder um eine fehlerhafte implementation,
oder um ein absturz, netzwerkfehler, ...
ohne makrojournaling erhaelt man dann einen teil (undefiniert
wieviel) des neuen inhaltes. - das system (die datei) ist also in einem
undefiniertem zustand.
mit makrojournaling behaelt man den alten inhalt, und zwar vollstaendig.
das system (die datei) befindet sich also weiterhin in einem definierten
zustand. - das ist mir allemal lieber.

wenn ich sicher gehen will, dass meine soeben geschriebenen daten auch
wirklich geschrieben werden (weil ich gerade an einem wohldefinierten
punkt bin, und die daten wichtig sind), dann sync()e ich. (auch ohne
makro-journaling). es kommt aber extrem selten vor, dass man eine
datei fuer laengere zeit schreibend geoeffnet haelt (ausser bei 
logfiles, aber da die i.d.r. mit O_APPEND geoeffnet werden, ist
makro-journaling auch nicht aktiv). in allen faellen die mir in den
sinn kommen, wo soetwas sinnvoll waere (z.b. um den zustand eines
programms fuer den naechsten aufruf festzuhalten) ist auch das 
O_SYNC - flag erforderlich.

nachteile sind:
* geringfuegiger performance-verlust. duerfte aber deutlich geringer
sein (ohne getestet zu haben) als normales journaling (das man aber
vielleicht zusaetzlich haben will).
* temporaer erhoehter festplattenbedarf.
in betriebsumgebungen, in denen das nicht akzeptabel ist, kann man
makro-journaling halt nicht benutzen.



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

das musst du mir erklaeren. wie kommst du darauf, dass journaling dazu
fuehren koennte, dass daten eher geschrieben werden? im gegenteil. wenn
waehrend der schreiboperation ein crash kommt, wird die situation von
vor dem schreiben wieder hergestellt.
im grunde ist data-journaling zu gar nix gut. ausser dem user eine 
schein-sicherheit vorzugaukeln. data-journaling bringt nur dann etwas,
wenn die anwendung die daten in logischen einheiten schreibt. 
beispielsweise, die anwendung schreibt zeilenweise, dann stellt
data-journaling sicher, dass nicht nach halben zeilen abgebrochen wird.



>Erweitern ist etwas anderes als Aendern des Verhaltens von Filesystemen.

fast jedes feature veraendert das verhalten von filesystemen. aber auch
mit makro-journaling verhaelt sich das fs immer noch gemaess den
spezifikationen. kommt aber der logischen sichtweise einer open-close-
transaktion naeher.


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

konnte nix darueber finden :-/


-- 
Don't worry be happy ...
Ciao Frank
-------------- nächster Teil --------------
Ein Dateianhang mit Binärdaten wurde abgetrennt...
Dateiname   : nicht verfügbar
Dateityp    : application/pgp-signature
Dateigröße  : 189 bytes
Beschreibung: nicht verfügbar
URL         : <https://mlists.in-berlin.de/pipermail/linux-l-mlists.in-berlin.de/attachments/20070418/ef473bcc/attachment.sig>


Mehr Informationen über die Mailingliste linux-l