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

[Frank Reker]

Am Thu 19. Apr 2007 14:08 +1000 schrieb Peter Ross:

>On Wed, 18 Apr 2007, Frank Reker wrote:
>> 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???
>
>Ich glaube, ich habe das Problem, das ich Dich nicht verstehe, da Du "fuer
>einen teilaspekt kein festgelegtes konzept hab, da es fuer das eigentliche
>problem nicht relevant ist."
>
>Druecke Deinen Teilaspekt noch einmal klar aus, dann muessen weder ich
>noch der Kernel noch sonstwer raten;-)

was ist an dem satz:
---snip---
>> macro-journaling nur bei bereits bestehenden dateien aktiviert werden
>> sollte oder auch dann wenn die datei neu erzeugt wird, ist
>> ansichtssache.
---snap---
so schwer zu verstehen?? zumal ich genau eine mail vorher schrieb:
---snip---
wenn die datei neu angelegt wurde, ist das ziemlich egal. wenn die datei
aber ueberschrieben oder veraendert wurde, ...
---snap---

es geht darum, was passieren soll, wenn eine neue datei angelegt wurde,
aber nicht geschlossen wurde. sollte die datei dann geloescht werden oder
halb stehen bleiben? meine aussage dazu war, dass mir das egal ist, da
es das eigentliche problem nicht betrifft. es geht mir einzig darum, 
dass wenn eine datei _ueberschrieben_, bzw. modifiziert wird, dann
die operation transaktionsorientiert ausgefuehrt wird, also ganz oder
gar nicht. die entscheidung darueber ob das auch bei neu erzeugten
dateien geschehen soll, ueberlass ich gerne anderen. 
aber wenn du unbedingt ne konkrete aussage dazu hoeren willst, dann
definier ich hier und jetzt: nein - makro-journaling wird nur beim
ueberschreiben aktiviert, und damit hat sich diese diskussion um 
unwichtige details erledigt, und niemand muss raten....

(ich komm mir bei solchen wortklaubereien immer vor wie im kindergarten).


>Ums kurz zu machen: Wenn Du Transaktionen im Datenbank-Sinne willst, nutze
>eine Datenbank, dafuer ist sie da. Wenn's eine Datei ist, mache eine
>Tabelle draus.

...und lehre alle programme wie vim, ooffice, ... mit datenbanken anstatt
mit dateisystemen umzugehen???


>Ich will das nicht im "normalen" Filesystem, da erzeugt es nur Overhead
>fuer alle Dateien, um Deinen Wunsch zu entsprechen.

ich nehme an, du benutzt auch kein herkoemmliches journaling, richtig???
ok - ist geschmacksache - es gibt auch leute die schwoeren
auf fat...

zum erzeugten overhead:
wird eine datei ueberschrieben wird sie normalerweise erst truncated
also auf null gekuerzt, also (mit ausnahme der inode) geloescht und
anschliessend eine neue datei angelegt. mit makro-journaling wird
erst eine neue datei erzeugt, und dann die alte geloescht. die
vorgaenge sind also die selben, nur in anderer reihenfolge. zeitlich
also kein mehraufwand, lediglich temporaer hoeherer festplattenbedarf.
wird eine datei modifiziert, muessen alle vorgaenge mitprotokolliert
werden, um sie spaeter wieder rueckgaengig zu machen. das verursacht
einen mehraufwand. ist (bisheriges) daten-journaling aktiv, geschieht
das genauso, lediglich das diese informationen frueher wieder geloescht
werden. bei eingeschaltetem data-journaling ist makro-journaling also
kein (oder minimaler) mehraufwand. lediglich wie gehabt ein temporaer
hoeherer plattenbedarf.


>Ich moechte ein performantes OS, und ich brauche das - fuer Server, die
>u.U. tausende Dateien in einer Minute anfassen.

dann solltest du aber auch herkoemmliches journaling deaktivieren.


>Ich glaube, Herr Reiser hat darueber nachgedacht.. geruechteweise ist
>reiserfs intern eine Datenbank, mit VFS-API.. aber wie gesagt -Vorsicht,

reiserfs benutzt b-baeume. eine technologie die auch in datenbanken
eingesetzt wird. eine datenbank im engeren sinne ist es deshalb aber
nicht. ok - im erweiterten sinne ist jedes fs eine datenbank.


>> im grunde ist data-journaling zu gar nix gut. ausser dem user eine
>> schein-sicherheit vorzugaukeln.
>
>Dann frage mal, warum es da ist? Meinst Du, Leute entwickeln etwas nur aus
>Spass an der Freude?

nicht selten werden sachen nur aus prestige-gruenden oder aus scheinbaren
vorteilen, die aber nicht wirklich viel bringen entwickelt. und
daten-journaling gehoert dazu. unter ext3 hat man es aufgrund der
eigenen journaling-schicht praktisch frei haus bekommen. also mussten
andere fse nachziehen.


>Nein, ein Journal ist eine Datei, da kann sequentiell hineingeschrieben
>werden, das ist schneller, als Daten auf zig Bloecke zu verteilen (nach
>wie vor ist das Suchen von Bloecken auf einer Platte eine extrem teure
>Operation).

auch diese datei ist auf zig bloecke verteilt, genau wie jede andere
auch. uebrigens benutzt reiserfs sogar wandernde journals um die
performance zu verbessern.



>Man kann das Journal gar woanders hinlegen, auf ein besonders schnelles
>Speichersystem, um das _erstmalige_ Schreiben zu beschleunigen. (Deshalb
>die Option device=external-journal in mke2fs)

am besten auf eine ramdisk ;-)) - im ernst: viel schnellere medien
als festplatten (ausser eben ramdisks) waeren mir nicht bekannt.
der vorteil bei externen journals liegt darin, dass (wenn auf zwei
festplatten verteilt) schreiboperationen parallelisiert werden,
und dadurch der performance-verlust durch doppeltes schreiben
wieder relativiert wird. wenn man also mehrere (scsi-)platten hat,
kann es also vorteilhaft sein die journals auf die jeweils andere
platte zu legen.


>Die App bekommt das okay, die Daten sind sicher, und wenn es dann crasht,
>kann das Transferieren aus dem Journal nach dem Neustart abgeschlossen
>werden.

es sei denn es crasht schon beim ersten schreiben, dann werden die daten
aus dem journal wieder geloescht, ohne sie in die eigentliche datei
zu uebertragen. und das schreiben ins journal ist nur unwesentlich
schneller als das eigentliche schreiben.

im uebrigen bekommt die app u.u. auch ein ok wenn die daten (noch) nicht
geschrieben wurden. die fehlermeldung kommt _dann_ erst bei weiteren
operationen (weiteres write (nicht zwingend), sync oder close).
ein verbreiteter fehler ist es daher den rueckgabewert von close nicht
auszuwerten, wodurch fehlgeschlagene writes u.u. unentdeckt bleiben.


-- 
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/20070419/d5b0f2b5/attachment.sig>