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

[Jan Krueger]

On Monday 18 August 2003 05:04, Peter Ross wrote:
> Hi Steffen,
>
> On Fri, 15 Aug 2003, Steffen Dettmer wrote:
> > Übrigens gibt es da noch etwas, und zwar LVM Snapshooting.
> > Hiermit kann man sowas erreichen: Vor dem Erzeugen der Datei
> > zieht man sich einen Snapshoot. Dann legt man die Datei an. Auf
> > dem snap passiert nichts. Am Ende schmeißt man den snap weg und
> > holt sich einen neuen. Die Datei ist "ruckartig" da und war nie
> > halb zu sehen. Es gibt also selbst diese Möglichkeit. Das ist
> > prima für Backups. Beim Verify wird es immer noch stimmen. Man
> > muß die Prozesse nur ganz kurz runterfahren, um den Snat zu
> > ziehen. Während der (langen) Backupdauer kann man ganz normal
> > weiterarbeiten. Ist schon schick.
>
> Das Runterfahren der Prozesse wird ein notwendiges Zugestaendnis daran
> sein, dass eigentlich LVM die falsche Schicht ist.
>
> Wenn Du ein staendig konsistentes Filesystem hasst, ('tschuldigung, hast,
> der Verschreiber ist aber zu schoen;-) dann brauchst Du auch das nicht (da
> die LVM aber nur eine Sammlung von Bytebloecken ist, kann sie nicht
> wissen, ob der Snapshot jederzeit konsistent ist).
>
> Im allgemeinen findett ein Copy-On-Write statt, d.h., wenn ein Bereich
> ueberschrieben wird, wird jetzt der alte stehengelassen und ein neuer
> geschrieben.
>
> Natuerlich muss der Snapshot die alten Daten wiederfinden. Je groesser die
> Aenderungen sind, um so groesser der Overhead fuer die nun doppelte
> Datenhaltung (zum Anfang kostet das annehernd nichts).
>
> Deswegen sollte man auch Snapshots in endlicher Zeit wegschreiben und dann
> wegwerfen - als Zweitkopie (wenn eins schiefgeht, nehme ich halt den
> Snashot von gestern) taugt es nur bedingt.
>
> Wegen o.g. Konsistenzbedingungen ziehe ich einen Snapshot auf
> Filesystem-Ebene vor.

Hallo Peter,

Das würde mit ext3,jfs,reiserfs,xfs nicht viel ändern.
Was würde passieren mit fürs Schreiben geöffneten Dateien während des 
Filesystem Snapshots?
Sie währen aus Sicht der Anwendung genau so "vollständig" wie beim LVM 
Snapshot. Bei ext3 werden Daten zwar geloggt, aber eben nur quasi zum 
selbstzweck, von der anwendung nicht kontrollierbar. Der Snapshot kann also 
nach wie vor unvollständig (aus sicht der anwendung) geschriebene Daten 
enthalten.

erst reiser4 bringt das dafür notwenige verhalten, sprich alles kann atomar 
sein, transaktionen, mit. Wenn dies konsequent im Filesystem selbst genutzt 
würde, könnte das Filesystem immer auf zeitlich leicht ältere aber gültige 
Daten zurückgreifen, mit dem overhead den unterschied zwischen alt und neu zu 
loggen bis neu einen konsistenten (aus sicht der anwendung) Zustand erreicht 
hat. Es könnte sich also immer einen gültigen Snapshot zusammenbasteln oder 
sich vom LVM auffordern lassen einen zu basteln.

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: Diese 4 GB sind ein atom. dann kann LVM das Filesystem auch 
fragen: auf welchen Dateien läuft was ab und von diesen gib mir einen 
gültigen (voherigen) Stand und kann somit einen auch für die anwendung 
gültigen snapshot machen.

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.

Die Frage wäre: Wo soll das atomare Verhalten, Transaktionen implementiert 
werden? Im Filesystem oder im VFS?

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

Insofern vertrete ich auch die ansicht, daß Transaktionen in reiser4 nix zu 
suchen haben :)

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.

Dennoch empfinde ich reiser4 als schmuckes stück software welches die 
notwendigkeit für derartige dinge zeigt und den weg zum ziel verkürzt.

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.

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

Gruß
Jan

>
> Gruss
> Peter
>
> _______________________________________________
> linux-l mailing list
> linux-l at mlists.in-berlin.de
> https://mlists.in-berlin.de/mailman/listinfo/linux-l