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

[Jan Krueger]

On Tuesday 19 August 2003 13:16, Steffen Dettmer wrote:
[...]
> 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?

Ja. Da wir ja nach world domination streben, spielen die anderen Systeme 
irgendwanneinmal sowieso keine Rolle mehr ...

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

Das heißt doch lediglich nur, daß "Everything is a file" nicht konsequent 
umgesetzt wurde :)

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. Man könnte den Prozeß anhalten, 
shapshotten oder einen vorherigen snapshot laden und dann weiterlaufen lassen 
:)

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

Genau.

> 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. Möglich ist 
das und praktiziert wird es auch immer wieder.

Es würde die mozilla startup-time erheblich verringern.

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

langsam. Ok, schnell genug für einen menschen.

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

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

[...]

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

Ja, is billiger und schneller. So macht man es auch bei Hotswapfähigem 
Speicher.

[...]

> Yo, könnte man dann machen. Vermutlich kann ne richtig heiße
> Clustersoftware sowas auch. Aber auf Applikationsebene ist's
> vermutlich meist einfacher.

Ja, stimmt.

[...]

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

gut :)

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

[...]
stimme zu

> > 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?
Wegen der besonderen Eigenheiten von flash-speicher welche bei direct IO nicht 
berücksichtigt werden. 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), 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. 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.

[...]

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

Ja, hast ja recht, das funktioniert nicht.

>
> > > 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.
Offensichtlich. Was sagt Dein Chef dazu?

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

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.

[...]

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

Und gleich gehts weiter (hab die mails zusammengeführt):
[...]
> Dafür, daß man das bei täglich nur 100MB braucht und das
> vermutlich relationale Daten sind, bietet sich aber auch wieder
> ein DBMS an, und der Rest bleibt schnell ;)

Ja.

> > Der ganze Filesystem- und blocksonstewas-kram wird ja einfach umgangen,#
> ist 
> > völlig uninteressant in so einem SAN. just begin;
> > putDataWithEnourmousSpeed; 
> > commit;
> 
> Klar, trivial-Transaktionen sind natürlich einfach. Anderes
> Bespiel aus interaktivem Notebook-Tool:
> 
> 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

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

> Ist ja
> auch das typische Datenbankproblem: entweder verwendet man
> Transaktionen nur, um sich selbst längerdauerne "Zwischenstände"
> in eigenen Tabellen zu vermerken (baut sich das individuell
> nach), nimmt weniger strikte ISO level oder muß eben damit leben,
> daß bestimmte Synchronisationen teuer werden können.
>
> > Gigabyte-Atome durchs Netz jagen ...
> 
> :) Ist aber ein großes Atom :)

Wenn man sich überlegt, wieviele Zustände so ein Atom haben kann ...

> > 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)
 
> > SCSI, IDE und Filesysteme sind damit hinfällig (außer in den
> > Storage devices selbst).
>
> Ja, das hat man in so einer Infrakstruktur ja ohnehin gern :)
> 
> > Und wieder zeigt sich, daß DirectIO quatsch ist.
>
> Na, das ist jetzt aber kein logischer Schluß...

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.

> > Wo gehts zum Software-Patentamt? 
>
> Ist immer noch illegal, aber stört keinen. Das deutsche Patentamt
> sitzt in München. Dort sitzt AFAIK auch was europäisches.
> 
> Ich hoffe diese Mail wird gut archiviert :)
> 
> Moment, jetzt ist das ja allgemein bekannt... Tja, Schade, was
> :-)

Na dann machen wir einfach mal eine Umfrage in der deutschen und australischen 
Bevölkerung und stellen fest ob es allgemein bekannt ist :)

Gruß
Jan