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

Steffen Dettmer steffen at dett.de
Fr Aug 15 21:07:44 CEST 2003


* Jan Krueger wrote on Fri, Aug 15, 2003 at 16:49 +0200:
> On Friday 15 August 2003 09:00, Steffen Dettmer wrote:
> > * Jan Krueger wrote on Fri, Aug 15, 2003 at 06:01 +0200:
> > > Die Möglichkeit solch eine riesenriesenriesengroße Datei
> > > atomar, also entweder ist sie da oder nicht, zu schreiben gibt
> > > es in Linux im Moment noch nicht wirklich (ist glücklicherweise
> > > in Arbeit)
> >
> > Hast Du einen Link? ich ging immer davon aus, das ext3
> > funktioniert...
> 
> http://www.namesys.com/txn-doc.html
> Summary Absatz 2

Das das JFS von reiser nicht so vollständig ist wie ext3, hörte
ich schon :-)

Danke für den Link, den Anfang hab ich ja noch verstanden aber
dann aufgegeben ;) Enthält ja das, was ich letzens schrieb und
warum man DBs nicht auf Filesysteme aufbauen möchte.

> Alternativ:
> $ dd if=/dev/random of=/filesystem1/bla bs=4G count=1
> $ (mv|cp) /filesystem1/bla /ext3filesystem/blu &
> $ while [ true ]; do ls -l /ext3filesystem/blu; sleep 1; done
> 
> und schauen wie sich blu entwickelt. blu ist nicht einfach so
> da oder nicht da sondern blu erscheint und wächst stetig bis es
> seine 4G erreicht hat.

Doch, ich bin mir sicher, daß es nach einem ext3 recovery einen
Stand hat, den es wirklich einmal hatte. Ich erwarte keine
Phantonreads, beispielsweise, weil die Größe nicht zur Datei
paßt (also die Dateigröße laut Angabe größer ist, als die
verfügbaren Blöcke, und der letzte Block noch nicht geschrieben
ist). Das entspricht einer DB-Transaktion, die ständig commitet.
Man hat zwar "Zwischenstände" - so gesehen - jedoch immer einen
konsistenten. Wird ein Block A geupdatet und danch Block B, wird
man nach einem Crash nicht in die Lage kommen, daß Block B
geändert wurde, Block A jedoch nicht oder das beim Hinzufügen
eines Verzeichniseintrages mit Crash drei andere Dateien
verschwinden oder sowas.

> ein crash zwischendrin läßt blu in seinem zweifelhaften
> zustand, also es ist da, aber eben nicht vollständig 
> und je nach JFS sogar mit ungültigen Daten.

Ja, bei reiser mag das sein, keine Ahnung. Jedenfalls ist es da,
und korrekt da, es wird keine Datenblöcke aus anderen Files
enthalten oder nicht-initialisierte Daten haben, also konsistent
zu (irgendeinem) Zeitpunkt sein.

Anders geht das auch nicht so einfach, weil ja POSIX File I/O gar
keine Transaktionen spezifiert (soweit ich weiß ;)): wie soll man
also dem System sagen, daß eine Transaktion abgeschlossen ist und
andere Prozesse die Datei sehen dürfen?

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

> > Also, ein Plattenblock ist gern mal 4K bis 64K groß, oder?
> bei ext3, ext2, jfs, ufs, ffs usw. gibt es beim erstellen des
> Filesystems festgelegte Blockgrößen.
> reiserfs kennt auch eine Blockgröße, kann diese jedoch unterteilen und in 
> einem Block können daten mehrer dateien hausen.
> bei xfs kann man die blockgröße dynamisch seinen Anforderungen anpassen.
> zb. ntfs nutzt als blockgröße diese 512byte.
> Also, man wähle man ein schlaues FS und muß weniger schreiben lassen.

Eine IDE Platte beispielsweise kann gar keine einzelnen Bytes
schreiben, da bin ich mir wirklich ziemlich sicher. Ob der
Kernel-Layer das kann, wage ich auch zu bezweifeln. Schließlich
heißen die files auch blockdevices ;) Aber genug der Beispiele,
ich glaub, wir sind eh einer Meinung :-)

Jedenfalls fand ich, daß das eine interessante Diskussion war!

oki,

Steffen

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




Mehr Informationen über die Mailingliste linux-l