[linux-l] Transaktionen? und Prozessesnapshots für alle und jeden und überall und jederzeit

[Jan Krueger]

On Wednesday 20 August 2003 01:58, Steffen Dettmer wrote:
> * 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.

Also fasse man voneinander abhängige Prozesse zusammen zu einer Prozessgruppe 
welche dann jeweils zusammen gesnapshotted werden, das wird zu kompliziert ..
Wie soll das OS erkennen, welche voneinander abhängig sind?

Der Prozeß ist für sein error-handling selbst verantwortlich.

Also, wenn ein Mensch aus dem suspend- oder snapshot-modus aufwacht und die 4 
Wände um ihn rum sind umgefallen
(gibt es übrigens wirklich eine Story aus der Zeit, als in Spandau die U-Bahn 
gebaut wurde. Ich kannte da jemanden der in einem normalen Altbau zu der Zeit 
in Spandau wohnte, nachts aufgewacht ist und die Fassade ist vom Haus 
abgefallen weil durch die U-Bahn tunnel-bohrungen der Erdboden vorm Haus ein 
wenig abgesackt ist. Aus dem Wohnzimmer war dann sowas wie eine überdachte 
Terasse geworden. Er hat es glaube ich, nicht als Wohnwertsteigerung 
empfunden)
dann ist der mensch für das errorhandling selbst verantwortlich und muß sich 
entsprechend zurechtfinden. Das ist nun mal so wenn man snapshottet.
Das OS könnte dann höchstens die Hilfe geben, ein signal, hallo prozeß du 
warst gesnapshottet. ähnlich wie man einem sehr jungen, kleinen Menschen 
durch den natürlichen Umgang, beibringt: Du hast geschlafen - Jetzt sei 
aktiv. Dadurch lernt der sehr junge, kleine Mensch ein entsprechendes 
(Error)-Handling, welches beim Aufwachen wirksam wird. (auch boot-prozess). 

Also, wenn man ein Programm schreibt für ein OS, von welchem man weiß, daß es 
Prozesse einschläfern kann, dann kann man auch ein entsprechendes 
Error-Handling dafür installieren, besonders wenn man ein signal bekommt: du 
hast schlafen müssen, überprüfe dich und deine Umgebung.

So ginge es doch.
Ein Prozeß könnte, wenn er vom OS erstellt wird auch einen standard-handler 
für dieses Signal bekommen den er, falls er besondere anforderungen hat, 
erweitern kann.

Ähm, das Signal hat einer in weiser Vorraussicht ja schon eingebaut:
SIGCONT   19,18,25            Continue if stopped
(aus man 7 signal)
snapshotted und wieder geladen ist halt dann eine Interpretation von stopped.

[...]

Langsam ist nicht egal.

> Na ja, siehe eben oben! 
Na, ohne sleep!?

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

Und während der windows-Admin-Kollege sein VisualStudio started hat man das 
bash-script mit vi schon fertig geschrieben :)
Kenn ich :)

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

Dös wois i net. Ich wüßte es, wenn sie kein DirectIO macht -> read() und 
write(). Dies würde mir ein Gefühl der Sicherheit geben, ich könnte auf die 
Anwendung und deren IO Unix-Einfluß nehmen :) insbesondere wenn ich in einer 
außergewöhnlichen situation dazu gezwungen wäre. 

> > Deswegen sollte man, im Interesse der Haltbarkeit (Ein flash
> > speicher verträgt nur eine begrenzte 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?

Wenn ich mir die embedded Linux-Entwicklungen so anschaue (zb. eben JFFS oder 
JFFS2) dann nutz man auch weitestmöglich abstraktionen weil man sich ja damit 
nicht auseinandersetzen will, sondern man will eine anwendung schreiben.

> > ein spezielles Flash-FS nutzen, zb.  jffs, welches diese
[...]
> > > > 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.

Ja, klar. Auch bei dem was ich mache.

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

Eben. Diese beiden verhalten sich wie ein einziger. und der kann immer, weil 
er ja der einzige ist, halt intern doppelt.

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

Ok, es gibt augenscheinlich sehr komplizierte Transaktionen spätestens dann, 
wenn mehr und mehr externe Systeme eingebunden werden. Doch wenn das so 
kompliziert und damit schwer beherrschbar wird, ist vielleicht das gewählte 
Modell "Transaktion" das falsche und man hätte etwas besser geeignetes wählen 
sollen. Blos was?

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

Des Bundeskanzlingers Katze :)
Man betrachte nicht das sein oder nicht sein der Katze sondern das sein oder 
nicht sein jeder einzelnen Zelle der Katze ... und bekommt dadurch eine 
ungeheure Anzahl Möglichkeiten ...

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

mein Gigabyte-Atom hat 2^(Anzahl bits) zustände ;)

+ diejenigen zustände, die zutreffen wenn man gerade nicht hinschaut.

also insgesamt 3^(Anzahl bits) 
wobei ich eben unterstelle, daß es nur diese 3 Zustände (0, 1, beides 
gleichzeitig) gibt.

Das zeigt wie unvollkommen Computer heutzutage sind, weil sie nur 2 Zustände 
berücksichtigen.

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

Ok, wir machen keine halben Sachen und verarbeiten Gigabyteatome am Stück:
putDataWithEnourmusSpeed( /path/to/bla, data)

> > 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
Schon, nur halt nicht das read() und nicht das write() welches man sich mit
 man read
oder
 man write
anschauen kann, weil diese eben nicht direct sind und durchs VFS/LVM/FS gehen.
Und genau diese implementieren wir in Hardware.

> ausgeführt. Ob das ein Cachealgo war, oder ne Applikation, merkt
> doch die Hardware nicht?

Gruß
Jan