[linux-l] Dateien mit '/' im Dateinamen

Di Aug 19 13:16:11 CEST 2003

* Jan Krueger wrote on Mon, Aug 18, 2003 at 21:33 +0200:
> On Monday 18 August 2003 13:18, Steffen Dettmer wrote:
> > Ja, sowas bräuchte man dann. Dann müßte beispielsweise eine
> > Datenbank bei einem Client-Commit ein entsprechendes
> > Filesystem-Commit aufrufen. Dazu muß man sie dann aber
> > Filesystem-abhängig implementieren,
> Naja eben nicht, wenn das auf VFS ebene generisch mit
> entsprechendem userspace api gemacht wird.  Dann gilt es ja für
> alle drunterliegenden FS gleicherweise.

Wenn es denn die API benutzt! ext2 z.B. nutzt ja keine solche
API. ext4 vielleicht, klar, aber das FS muß speziell dafür
gemacht sein, was aber egal ist, denke ich, wichtig ist halt, daß
die Anwendung die API ja dann benutzten muß, also eben commit(2)
aufrufen muß oder so, was es nicht überall gibt. Muß man ja schon
fast zwei I/O Subsysteme bauen, eines was commit sinnvoll nutzt,
und eines, was auf anderen Systemen läuft. Oder?

> Richtig, so muß man es heutzutage machen. Generell halte ich
> Transaktionen damit nach außen atomares Verhalten auch
> innerhalb des Kernels für nützlich, um zum Beispiel Snapshots
> nicht nur von Nutz-Daten sondern auch Prozessen anfertigen zu
> können (Welche dann in Files gesichert werden und es damit
> entsprechend meiner vorher gechriebenen These legal wäre die
> Files als Prozesse zu bezeichnen :)

(klar, ein Programm, was nicht mehr ausgeführt wird, ist wieder
nur ein File :)).

Snapshots von Prozessen... mmm... Ich hab jetzt ne Weile drüber
nachgedacht, aber wohl nicht verstanden. Du kannst Prozesse
anhalten (SIGSTOP z.B.). Jetzt könnte man sich ein core file
ziehen (und das Snap nennen) und dann das Programm weiter laufen
lassen. Bringt aber doch nicht viel. Interessant wäre es, könnte
man das core wieder "zurückspielen". 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).

> Man denke hier zum Beispiel an die damals großen
> Vor-Unix-Systeme bei welchen ein fehlerhafter Prozess
> angehalten wurde, ein debugger draufgesetzt wurde und der
> kombinierte Maschinenprogrammieradministrator das Problem
> beseitigen konnte um danach den Prozess weiterlaufen zu lassen.

Was gefällt Dir am gdb nicht? 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);
}

Hat mir neulich gerade wieder geholfen (gut, war da nur'n sleep
30 ;)). Dann sieht man schon mal, wo es denn nu eigentlich gehakt
hat. 

BTW, kann man als Prozeß eigentlich nicht sogar selbst sagen:
"ich schreib jetzt mal ein core file"?

> So ein Prozeßsnapshot ließe sich also beliebig "reparieren" und
> nochmals starten (erinnert irgendwie an "Lola rennt" von Tom
> Tykwer :)

Das geht ja mit dem gdb. Kannste in aller Ruhe alles ändern und
weiter laufen lassen. Wenn man das möchte. Meistens möchte man ja
nur das Problem finden, Testtreiber bauen, Problem beheben. Sonst
sitzt man später vor'm Debugger: Mensch, was haben wir damals
noch gleich gemacht? Auf Assemblerebene war das mal beliebter:
HighTech-Debugger mit eingebautem Assembler zur Hand, und fix mal
die falschen Instruktionen geändert. call reinassembliert,
Funktion hinten dran, continue. Wenn es dann lief, wußte man aber
leider oft nicht mehr so genau, warum eigentlich. Die Änderungen
dann so in den Source zu übernehmen muß nicht in alle Fällen
funktionieren etc. Jedenfalls kann man hier auch mit Linux
ziemllich aufregende Sachen machen, find ich ;)

> Außerdem könnte das Kernel sich nach außen robuster verhalten
> wenn Hardware Fehler aufweist. 

Ja, stimmt. Aber das wird verdammt teuer, wenn man seiner
Hardware nicht traut (besonders auf Hardware, die nicht dafür
gemacht ist). Ich denk mal, ein wichtigerer Armeecoputer macht
sowas. Da werden dann redundante Codes im Arbeitsspeicher benutzt
und kaputte Bänke einfach abgeschaltet, sicherlich alles
Hotswapfähig - aber auch schweineaufwendig und damit teuer.

> Statt auf storage system a wurde
> auf storage system b gesichert, weil a fehler aufwies und die
> transaktion nicht erfolgreich abgeschlossen werden konnte. zum
> glück wurden die notwendigen daten auf c geloggt, also war ein
> erfolgreicher abschluss der transaktion auf b möglich, für die
> anwendung völlig transparent und atomar.

Na ja, so ungefähr funktioniert ja ein RAID. RAID4 vielleicht
(das ist 5 mit reservierter Parityplatte). Man erkennt einen
Fehler nicht-destruktiv, nimmt sich ein Sparedrive und weiter
geht's.

> Prozeßsnapshots werden ja heute schon in Linux genutzt,
> allerdings nur für sonderfälle: core-dump und hibernation

Natürlich ist ein core-dump *irgendein* Zustand, den die
Anwendung (in der Regel) nicht selbst beeinflußt. Kann also gut
sein, daß ein string gerade zur Hälfte kopiert ist etc.

> Man stelle sich einen billigen Linux Compute-cluster vor. In
> einem Knoten fallen Lüfter aus -> schnell einen Prozeß-snapshot
> machen -> sichern -> auf einen neuen Knoten verschieben ->
> starten und der Prozeß merkt nix davon.  ([open-]mosix kann das
> fast)

Yo, könnte man dann machen. Vermutlich kann ne richtig heiße
Clustersoftware sowas auch. Aber auf Applikationsebene ist's
vermutlich meist einfacher. Renderste Grafiken und fällt ein Node
aus, rendeste das betroffene Bild eben einfach nochmal.

> > Denke, daß ist verdammt kompliziert, schon allein, weil es viele
> > Transaktionsarten gibt. Müßte ja jeder Prozeß für sich einstellen
> > können etc. Denke, daß läuft dann auf eine TransaktionsAPI
> > ähnliche der SQL Transaktionen raus; da braucht man schon bißchen
> > was. Wird dasn vermutlich gleich auch nicht-trivial in der
> > Anwendung. Dann hat man ne komplexe, fehlerträchtige Software,
> > die man in 99% der Fälle überhaupt nicht braucht. Möchte man das
> > wirklich?
> Möchte man also wirklich oracle verwenden? ;)

Ich glaub, man möchte wirklich ein DBMS, ja... :)

> oder:
> /dev/bla /mnt/balla vfs      layout=oracle,logging=data,transactions=yes 0 0
> 
> Sieht doch schick aus, oder?
> 
> Dies legt natürlich das default-mäßige Verhalten fest. Dank des
> userspace api kann das pro datei von der anwendung natürlich
> erweitert werden, also wenn das FS logging=meta hat, kann die
> anwendung für eine datei logging=data beantragen.

Das hilft ja nicht. Die Anwendung muß ja Funktionen wie
"begin_work(2)" und "commit(2)" aufrufen, damit das System weiß,
was denn nu eigentlich ne atomare Transaktion überhaupt ist. Die
Software muß man also anpassen, vermutlich redesignen, sowas kann
man vermutlich oft schlecht nachbauen (oder man macht's auf hoher
Ebene, klar). Der Kernel wird superkomplex, schließlich braucht
man auch deadlock detection etc, sonst kannste Dich nicht
anmelden, weil ein hängender Prozeß /etc/wtmp gelesen hat und
damit schreiblocks verbietet.

Mir fällt auch - von typischen Datenbankanwendungen - kaum ein
Beispiel ein, wo das deutliche Vorteile gegenüber synchronem
Schreiben bringen könnte. Für die meisten Anwendungen reicht ja
flock. Gut, man könnte in einer Admin-Transaktion alles locken
und dann bei laufendem Betrieb /usr/ verschieben, atomar einen
symlink anlegen, wenn man einen Zeitpunkt erwischt, wo nichts
offen ist, das System wartet dann so lange. Natürlich auch login
shells. 

> > Find ich auch, wäre doof, wenn sich z.B. ne DB je nach
> > Filesystem anders verhalten würde, denke ich.

Dann muß die API unbedingt allgmein und sehr genau definiert
sein. Das wird auch wieder schwierig. Aber man kann ja mit ISO
Transaktionsleveln anfangen.

> An diesem Punkt wird auch deutlich wie abhängig direktIO vom
> drunterliegenden Speichersystem, bzw. von der Annahme der
> Anwendung, wie was das drunterliegende Speichersystem zu sein
> hat, ist. Man stelle sich vor, oracle nutzt flash-speicher über
> direcktIO... whoaa, ein unding. niemand würde heutzutage
> soetwas machen.

Warum? Kann man doch transparent abbilden? Gibt doch auch
flash-Speicher?

> durchs VFS ist das ohne weiteres möglich. WEnn das VFS dann
> noch transaktionen unterstützt: prima. gerad bei flash speicher
> können ja fehler auftreten -> fehler melden und woanders
> sichern.

Das typische Transaktionsverhalten wäre rollback, nicht
Korrektur. Sind zwei verschiedene Sachen, finde ich.

>   (Und vielleicht es bald sogar notwendig wenn unsere
> Linux-Handys wegen der langsamen Funk-Verbindungen mit einem
> Snapshot des Internet, oracle machts möglich, ausgeliefert
> werden ;)

Snapshot des Internet wäre natürlich praktisch. Hat man google
und alle Links offline dabei! Prima. Könnte auch ein Proxycache
prima ausnutzen!

> Also wäre es hier von vorteil, wenn das Kernel selbst das in
> die hand nehmen kann und das intern regelt, den optionen in
> fstab entsprechend, dann muß keiner mitmachen und doch machen
> alle mit ohne es zu wissen. ein callback wäre tatsächlich
> sinnlos.

Das *geht* aber doch nicht! Woher soll der Kernel dann wissen,
daß die ersten 17 writes die erste Transaktion, die folgenden 4
reads und 2 writes eine zweite sind? Und nicht etwa das das eine
oder drei Transaktionen sind? Versuch doch mal, daß in
Pseudo-Code aufzuschreiben... Das kann doch gar nicht
funktionieren.

> > Mit LVM kann man viel davon machen, die API heißt sql stop ;
> > snap ; sql start :-) Ist sicher, einfach und unkompliziert.
> > Und vor allem: transparent. Mir gefällt das gut.
> 
> 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.

> Ah, ich weiß: Einen cluster bauen: heartbeat stop auf dem
> einen, der andere übernimmt, den einen snappen, heartbeat start
> auf dem einen, synchronisation mit dem anderen, den snap vom
> einen sichern, fertig. ja, geht auch.

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. 

Technisch kann man das ganz einfach lösen: man nimmt kleine
Transaktionen (klar, sowieso). Wenn die Datenbank gerade nicht da
ist, wartet man zweimal zehn Sekunden oder so und versuchts
nochmal. Dann ist die schon wieder oben und bis auf einen 10
Sekündigen Delay merkt man nix. Das reicht sicherlich meistens.

> Welche open-source Linux DB kann man auf obige weise clustern?
> sprich: beide arbeiten parallel auf der selben DB und auf beide
> kann gleichzeitig schreibenderweise zugegriffen werden?

Ich glaub, daß reicht noch nicht mal :)

Aber wie man an dem Thread erkennt, es ist ein verdammt komplexes
Thema.

oki,

Steffen

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