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

[Peter Ross]

Hi Frank,

(zweiter Versuch des Senden, fallback-mx.in-berlin.de hat mir erzaehlt, 
dass er die Mail fuer 24 Stunden nicht zustellen konnte, hoffentlich ist 
da alles okay)

On Wed, 18 Apr 2007, Frank Reker wrote:

> sprechen wir eigentlich die selbe sprache?

Gute Frage;-)

> 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;-)

> >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?!

Um im Bilde zu bleiben:

Wozu einen zweiten Druckertreiber schreiben, nur weil die App zu daemlich
ist, den ersten zu nutzen;-)

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.

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

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

Wenn ich ein Feature fuer eine Datei will, muss ich das fuer ein
Filesystem aktivieren, und das ist mir zuviel.

Ich glaube, Herr Reiser hat darueber nachgedacht.. geruechteweise ist
reiserfs intern eine Datenbank, mit VFS-API.. aber wie gesagt -Vorsicht,
dies habe ich nicht selbst erforscht.

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

Dann frage mal, warum es da ist? Meinst Du, Leute entwickeln etwas nur aus
Spass an der Freude?

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

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)

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.

Gruss
Peter