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

Mo Aug 18 21:33:48 CEST 2003

On Monday 18 August 2003 13:18, Steffen Dettmer wrote:
> * Jan Krueger wrote on Mon, Aug 18, 2003 at 06:20 +0200:
> > Dies Verhalten müßte natürlich von der anwendung zu steuern sein, also
> > ein entprechendes api muß existieren, damit die anwendung dem Filesystem
> > mitteilen kann:
>
> 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.

> und ich denke, daß möchte man
> nun auch wieder nicht unbedingt, oder?
>
> > Die alternative wäre, daß man alles unterhalb VFS als atomar
> > betrachtet, was aber ein vom heutigen dasein sehr stark
> > abweichendes verhalten wäre und damit vieles zum bersten
> > bringen würde.
>
> Na, und dann geht ja gar kein Elevator-Seeking beim Schreiben.
>
> > Die Frage wäre: Wo soll das atomare Verhalten, Transaktionen
> > implementiert werden? Im Filesystem oder im VFS?
>
> Oder in der Datenbank? ;) Die sind ja prädestiniert dafür.

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

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.

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

Außerdem könnte das Kernel sich nach außen robuster verhalten wenn Hardware 
Fehler aufweist. 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.

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

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)

> > Ich bin der Ansicht im VFS. filesysteme sollten diesbezüglich
> > dumm sein und lieber die Daten g'scheit organisieren. atomares
> > verhalten und transaktionen kann man auch generisch darüber
> > machen und per api dem userspace verfügbar machen und dann, ja
> > dann, könnten das sogar Datenbanken zu ihrem vorteil nutzen :)
>
> 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? ;)

Man stelle sich das praktisch als Eintrag in /etc/fstab vor. bisher:
/dev/bla /mnt/balla reiserfs noatime                                     0 0
Jetzt neu:
/dev/bla /mnt/balla vfs      layout=btree,logging=meta,transactions=no   0 0
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.

> > Insofern vertrete ich auch die ansicht, daß Transaktionen in
> > reiser4 nix zu suchen haben :)
>
> Ja, denke auch, daß das nur für sehr spezielle Anwendungen Sinn
> macht. Diese verwenden vermutlich trozdem lieber ne Datenbank.
>
> > Und richtig, die verschiedenen journalling-techniken sollten,
> > je nach bedarf, modular ins/ans VFS zu hängen sein, ebenso wie
> > die transaktionsfähigkeit usw.
> >
> > Ein Filesystem sollte lediglich das layout der Daten auf der
> > Platte bestimmen und verwalten, mehr nicht.
>
> Find ich auch, wäre doof, wenn sich z.B. ne DB je nach Filesystem
> anders verhalten würde, denke ich.

Genau. Das Filesystem darf sich gerne anders Verhalten, zum Beispiel die Daten 
anders organisieren, der Anwendung (DB) sollte das egal sein.

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.

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

> > Noch idealer wäre es, da auch Filesystemtransaktionen lange
> > dauern können, nehmen wir als Beispiel mal 24 Stunden aber alle
> > 12 Stunden soll ein konsistentes Backup mittels Snapshot
> > gemacht werden, wenn das Filesystem zurück-callen oder
> > -signalisieren könnte um der Anwendung zu sagen: Snapshot-Time,
> > Deine Transaktion läuft zwar noch, aber ich geb dir jetzt die
> > Chance mir umgehend etwas für dich konsistentes zu liefern
> > sonst nehme ich die Daten von vor 24 Stunden.
>
> Dann kannst Du Dich auf Dein Backup wieder nicht verlassen! Was
> soll eine Datenbank dann machen? Wenn es gar nicht warten darf,
> hat man ein Problem, wenn ein Client eine Transaktion offen hat.
> Natürlich könnte die Datenbank den "Rest" aus den vorherigen
> Transaktionen schon mal speichern, darf dann aber kurz nicht auf
> ihren Daten arbeiten (für die Dauer der Snapshoterzeugung), was
> auch schnell schwierig werden kann. Insbesondere wenn eine
> offene Transaktion garade mal 10K Records geändert hat, kann das
> sehr kompliziert werden, denke ich. Vermutlich geht es dann
> einfach nicht, aber genau dann würde es Sinn machen. Könnte mir
> eher vorstellen, daß die DB alle paar Minuten oder Stunden ne
> Funktion aufruft, die sagt: Ich bin zufällig jetzt gerade
> definitiv konsistent ("commit"). Ist dann natürlich auf VFS Ebene
> wieder schwierig, weil das selten von allen gleichzeitig kommen
> kann. Also muß das FS natürlich change-set-views implementieren:
> Ein Prozess sieht nur commitete-Transaktionen, und muß Buch
> führen, welche Transaktionen gerade offen sind. Wenn ein Job dann
> in einer Transaktion 1 GB Daten benutzt, wird das schnell teuer.
> Außerdem ist das auch für die Tools nicht so einfach. Wenn Du ein
> rm auf ne Datei machst, die nicht geöffnet aber in einer noch
> offenen Transaktion gelesen wurde, muß das rm schiefgehen, weil
> die Datei gelockt sein muß, weil man sonst ja wieder was
> inkonsistentes hätte usw. Heißt: da müßten dann alles mitmachen,
> sonst ist es wie bei flock: ist was freiwilliges, und genau
> deshalb kann man Probleme bekommen :)

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.

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

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?

oh, ich kann mich erinnern, es gab mal ein linux-distri-project welches als 
storage eine richtige (XML?-)Datenbank verwenden wollte, dateien als 
db-einträge waren. weiß jemand was darüber? Muß mal googlen. Find nix. Is 
wohl verschollen.

Gruß
Jan

> > > Ich habe mal eben gegooglet, leider erfolglos.. Kann
> > > das eines der Linux-FS?
> >
> > Vielleicht ein kommerzielles, die von linus-kernel können es nicht.
> > Welches Filesystem kann das?
>
> Taugt die API was? Gibt es Software, die das richtig ausnutzt?
> Ist die API sinnvoll und vollständig, oder nur wieder ein Schritt
> mehr in diese Richtung?

> oki,
>
> Steffen