[linux-l] Transaktionen für alle (was: Re: [linux-l] Dateien mit '/' im Dateinamen)

[Steffen Dettmer]

* Jan Krueger wrote on Tue, Aug 19, 2003 at 20:40 +0200:
> On Tuesday 19 August 2003 13:16, Steffen Dettmer wrote:
> > (klar, ein Programm, was nicht mehr ausgeführt wird, ist
> > wieder nur ein File :)).
> 
> Das heißt doch lediglich nur, daß "Everything is a file" nicht konsequent 
> umgesetzt wurde :)

Es gibt's ja trozdem noch als File.

> Man braucht doch nur den entsprechenden Bereich aus /dev/kmem
> unter /proc/pid/procmem "mounten" und hätte den Prozeß als File
> ständig und jedderzeit selbst während er ausgeführt wird.

Ja, kannste bloß nix mit anfangen. Wie wenn der gdb merkt, daß
der Thread in einem Deadlock ist. Gut zu wissen, aber nicht
korrigierbar...

> > Natürlich auch wieder doof,
> > weil nicht mehr alle Daten mit der Umwelt konsistent sein müssen
> > (hat man bei DBs natürlich auch, aber sieht das oft besser).
> 
> Restrisiko :)
> Wenn ein Mesch sich snapshottet, ein weilchen schläft, und dann
> wieder bootet darf sich die umwelt natürlich nicht zu stark
> verändert haben. 

Umwelt schließt hier ja die anderen Prozesse mit ein, und die
verändern sich in der Zeit sicherlich Millionen Male...

Schon ein kooperatives suspend-to-disk ist nicht so ganz einfach.

> > Was gefällt Dir am gdb nicht?
> 
> langsam. Ok, schnell genug für einen menschen.

mmm... Langsam? Ist doch egal?

> > Ich verwende manchmal so eine
> > Technik:
> >
> > int signal_hold(int signal)
> > {
> >    switch (signal) {
> >       case SIGSEGV: /* ... */
> >                     break;
> >       default return;
> >    }
> >
> >    /* Libc Funktionen sind hier keine wirklich gute Idee. */
> >    fprinf(stderr, "\n\n\n***\n*** Fatal sig %d - process hold.\n"
> > 		  "*** attach gdb to PID=%d\n\n\n",
> > 		  signal,
> > 		  getpid()
> >    );
> >
> >    sleep(1000);
> > }
> 
> So geht es auch.
> 
> > ... Jedenfalls kann man hier auch mit Linux
> > ziemllich aufregende Sachen machen, find ich ;)
> 
> Hm, gut, kann ich denn, wie die alten systeme, ehe ein programm ein 
> core-dumped und aus dem Speicher verschwindet automatisch einen gdb ansetzen 
> lassen?

Na ja, siehe eben oben! Genau dafür ist das da. "hängt" dann eben
(für hier 1000 Sekunden, ist ja egal), kann man gdb reinhängen
und mal nachgucken, was da los war. Vorteile gegenüber core dumps
sehe ich nicht wirklich, bloß manchmal geht coredump nicht so
gut (weil man vielleicht nur an jedem 10. interessiert ist oder
so, hängt von vielem ab).

> > Mir fällt auch - von typischen Datenbankanwendungen - kaum ein
> > Beispiel ein, wo das deutliche Vorteile gegenüber synchronem
> > Schreiben bringen könnte.
> 
> Genau, dies ist der entscheidende Punkt, welche Transaktionen
> im Kernel überflüssig machen. Jetzt, nachdem ich nochmal drüber
> nachgedacht habe und Du das quasi bestätigts, komme ich wieder
> zu dem Schluß, daß ordered und synchrone writes völlig
> ausreichend sind.

Yep, geht mir genauso. Das ist das schöne an Unix: man denkt
lange drüber nach und kommt auf gleiche Ideen. Bei Windows ist
das eher anders. Dann fragt man sich eher, warum man ausgerechnet
*das* nicht auch noch abscheiben konnte und installiert sich ein
cygwin ;)

> > > Man stelle sich vor, oracle nutzt flash-speicher über
> > > direcktIO... 
> >
> > Warum?

> Wegen der besonderen Eigenheiten von flash-speicher welche bei
> direct IO nicht berücksichtigt werden. 

Woher weißt, was meine Applikation da macht?

> Deswegen sollte man, im Interesse der Haltbarkeit (Ein flash
> speicher verträgt nur eine begranzte anzahl Schreib-Zugriffe,
> wenn man diese also immer auf dem selben block ausführen würde,
> würde nach einiger Zeit genau dieser Block defekt werden), 

Ja, natürlich, alle bekannt (und trozdem von irgendeinem
Ork-Patentamt patentiert), klar, kann man aber auch auf
Applikationsebene handhaben. Ist im Embedded-Bereich (wo es ja
oft nur sowas wie "direkt IO" gibt) auch sehr üblich, oder?

> ein spezielles Flash-FS nutzen, zb.  jffs, welches diese
> Eigenheiten berücksichtigt, und zum Beispiel schreibzugriffe
> möglichst gleichmäßig über den gesamten Flash-speicher
> verteilt. 

Hier kann man teils recht einfache algorithmen nehmen,
beispielsweise schreibe den Block auf einen zufällig gewählten,
freien oder sowas in der Art. Beim Ur-Verzeichnis muß man bißchen
trixen. 

> Dies macht Oracle bei DirectIO natürlich nicht, ganz im
> gegenteil, es ist bemüht diese Art der Zugriffe zussammen zu
> halten, unter der annahme, daß der darunterliegende Speicher
> eine Platte ist welche beim verteilen der zugriffe langsamer
> wird.

Ja, klar, weil es anders keinen Sinn macht. Sonst würde Oracle
damit sicherlich auch vernünfig umgehen können. Ich geh davon
aus, das viele ganz kleine Embedded-Datenbank sowas kann, weil es
hier Sinn macht (da gibt's zumindestens etliche auf'm Markt).

> > > Hihi, Und was machst Du, wenn die Anforderung 24/7 ist? sql
> > > stop ist dann verboten und ein snap inkonsistent, also?
> >
> > Dann ist die Anforderung falsch.

> Offensichtlich. Was sagt Dein Chef dazu?

Er formuliert sie auf 99.9% von 24/7 um. Bleibt über eine Minute
am Tag. Verfügbarkeiten von 99.9% sind meist ausreichend,
zumindestens für das, was ich mache, in jedem Fall.

> > Kann mir nicht vorstellen, daß das funktioniert, ohne
> > Transaktionen abzubrechen *oder* zu verzögern, denn man braucht
> > ja einen Zeitpunkt, in dem es keine offenen Transaktionen gibt,
> > um umschalten zu können. Den gleichen Zeitpunkt, wie für das
> > Ziehen eines Snaps.
> 
> Da der eine und der andere letztendlich parallel die dinge
> ausführen, also exakt das gleiche tun (beide haben die gleichen
> offenen transaktionen laufen) muß lediglich die Anwendung ihre
> verbindung zum anderen umschalten.  klitzekleine verzögerung.
> der andere kann, da er ja alles bisherige auch ausgeführt hat,
> nahtlos übernehmen.

? Nee... Wenn jemand eine Datei liest, schreibt und nach 3
Stunden nochmal einen Block davon neu schreibt (also einen
exklusiven Lock hat), kann logischerweise 3 Stunden niemand
anders die Datei lesen, weil er ja nicht wissen kann, ob der
erste geschriebene Block commitet wird oder nicht. Man könnte
natürlich noch "views" dazunehmen, daß der andere dann die Daten
sieht, die es mal waren. Wird natürlich auch wieder teuer, weil
man dann alle View-Daten speichern muß (was natürlich jede
Datenbank  - außer vielleicht mySQL und "kleine" - kann, wo wir
wieder beim Thema wären ;)). Wenn beide schreiben wollen, muß auf
jeden Fall sequentialisiert werden, einer kann ja nur. Wenn nur
einer liest, und später seine Transaktion beenden (positiv,
commit) will, die gelesenen Daten aber doch geändert wurden (weil
die erste Transaktion auch positiv war), muß hier ein Rollback
gemacht werden (bei Datenbanken bekommt man dann ein Transaction
abort, sowas müßte man dann hier auch machen). Ist schon
schwierig.

> > begin
> > getDataWithEnourmousSpeed(notes)
> > MessageID = new
> > putDataWithEnourmousSpeed(notes, MessageID)
> > message = getDataFromUser(notes)
> > putDataWithEnourmousSpeed(notes, MessageID, message)
> > commit
> > 
> > Das notes-File ist hier für die Dauer von getDataFromUser
> > gelockt und kann von niemandem sonst verwendet werden, egal wie
> > schnell das Storage System ist, es ist doch "langsam".
> 
> message = getDataFromUser
> begin
> getDataWithEnourmousSpeed(notes)
> MessageID = allocateNewMessageID(notes)
> putDataWithEnourmousSpeed(notes, MessageID, message)
> commit

Natürlich mag das in diesem konstruierten Beispiel keine Rolle
spielen, ich hätte schreiben sollen:

message = getDataFromUser(notes, MessageID), C&P Fehler ;)

Natürlich nimmt man für MessageID was clevers, z.B. ne Sequenz,
dann geht das trozdem, schon klar, aber zeigt ja, was gemeint
ist.

> Ich beginne an der notwendigkeit für die Kompliziertheit von
> Transaktionen zu zweifeln ...

Das klassische Beispiel ist ja das Kontobuchen:

begin
select datensatz from soll where id = ?
insert datensatz into haben;
delete datensatz from soll where id = ?
commit

wenn z.B. insert lange dauern kann (jajaja, in dem Beispiel ist
das einfach, weil man keine externe Interaktion hat; aber
angenommen, das DBMS muß bei insert einen verlustfreien Datensatz
auf einem 9-Nadel-Drucker ausdrucken, sowas gibt's wirklich),
wenn das also lange dauern kann, ist der datensatz für diese Zeit
gesperrt. Der Zustand ist unklar: kann sein, daß er weg ist, kann
sein, daß er noch da ist, hängt davon ab, ob das commit am Ende
klappt oder nicht. Physiker würden sagen: "der Zustandsvektor ist
superpositiv und kollabiert bei commit". In welchen Zustand weiß
man aber erst dann! Und weil man mit Superpositionen schlecht
rechnen kann ;) muß man also locken, hilft ja nix.

> > > Gigabyte-Atome durchs Netz jagen ...
> > 
> > :) Ist aber ein großes Atom :)
> 
> Wenn man sich überlegt, wieviele Zustände so ein Atom haben
> kann ...

Wenn's superpositiv ist, bis zu nicht-abzählbar-unendlich viele,
würde ich mal raten, aber kenn ja Dein Atom nicht persönlich ;)

> > > Die Zukunft der Festplatten: Nix blocks mehr oder LBA oder so, nönö, just 
> > > begin;  putDataWithEnourmousSpeed; commit;.
> > 
> > Das putDataWithEnourmousSpeed verwendet kein
> > Addressierungsverfahren?!
> 
> putDataWithEnourmusSpeed( /path/to/bla, offsetInBla, data)

offsetInBla ist im LBA-Format, was? :-) Ist ja auch egal,
jedenfalls wird's wohl ne Zahl oder meintwegen auch ein Vektor
sein, egal, jedenfalls wirst Du sicherlich nicht Bits einzeln
adressieren können (und ein Byte ist schon wieder ein 8bit
Block). Wär auch einfach zu langsam.

> Isses doch, weil man mit DirectIO sich die möglichkeit der
> AcceleratedTransactions nimmt. Aber das ist ja eh quatsch.  Wir
> benötigen ja weiterhin nur read und write mit entsprechenden
> Flags, wie zb. sync, und diese implementieren wir einfach in
> Hardware und dann sieht man recht schön, daß directIO hier
> nicht funktioniert, weil es eben read und write gerade nicht
> verwendet.

Versteh ich nicht. Wieso merkt die Hardware überhaupt was von
directIO?! Hier wird ja eben ein read oder write Kommando
ausgeführt. Ob das ein Cachealgo war, oder ne Applikation, merkt
doch die Hardware nicht?

oki,

Steffen

-- 
Dieses Schreiben wurde maschinell erstellt,
es trägt daher weder Unterschrift noch Siegel.