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

[Steffen Dettmer]

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

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

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

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

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.

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

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