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

[Steffen Dettmer]

* Jan Krueger wrote on Fri, Aug 15, 2003 at 06:01 +0200:
> On Friday 15 August 2003 00:57, Steffen Dettmer wrote:
> > Eine DB muß eine laufende Transaktion überhaupt nicht auf
> > eine Platte schreiben, weil ja ein Rollback kommen kann und
> > bei einem crash das commit garantiert nicht klappt ;)
> 
> Eben. Crash, Du sagst es ja. Müssen muß sie nicht, aber können
> kann es die eine oder andere. 

Wie meinst Du das? Ich geh mal davon aus, daß jede nicht-triviale
Datenbank merkt, daß es bekloppt ist, offene Transaktionen zu
schreiben, wenn nicht notwendig. Dauert ja viel zu lange! 

> Damit die Daten und Informationen über die Transaktion im
> Zweifelsfalls nicht verloren gehen, werden Sie außerhalb der DB
> geloggt. 

Bei einem crash *müssen* die Änderungen der Transaktion verloren
gehen. Wozu also speichern, wenn genug RAM da ist.

> Dann wird versucht sie in die DB einzufügen. Falls das aus
> irgendeinem Grund vorläufig verhindert wird, zb. wegen eines
> anderes Locks auf dem Datensatz oder eines crashes, sind die
> Daten erst mal sicher.  

Wegen eines Locks? Wenn also ein Lock die Transaktion verlängert?
Dann besteht immer noch kein Grund, überhaupt was zu schreiben,
schließlich ist die Transaktion ja noch offen. 

> Also auch nach dem crash oder nach lock-freigabe könnten Sie
> recovered/eingefügt werden.

Wenn in der Transaktion ein crash und recovery stattfindet,
muß diese natürlich rückgängig gemacht werden (falls etwas
geschrieben wurde).

> Das JFS versucht doch, zumindest sich selbst konsistent zu
> halten - also müssen die Informationen irgendwie auf Platte und
> das kostet IO welcher dem DB IO verloren geht.

Ja, ich sag ja, im Maximalfall gleich schnell ;)

> > Eben, man macht das ja auch nicht aus Performancegründen.
> 
> Na aber warum denn dann?

Wegen der Sicherheit der Konsistenz.

> > Unterschied nicht auffallen sollte (von DBMSes mal abgesehen,
> > die 128 bit Dateien erzeugen ;-)).
> 
> Jain. Die erwähnte Objektorientierte Datenbank hat sich an
> pages orientiert und glaubte dadurch sehr schnell zu sein. 

Ja klar, alles andere ist langsam. Sowas wie mit 5000 Byte
Blöcken zu arbeiten oder Einzelbyteweise :)

> Das war sie auch, bei Daten die gut in pages passen :)
> ansonsten führte es eher zu IO-Verschwendung.

Das Schreiben eines physikalischen Blockes kostet Zeit. Ob der zu
5% oder 95% Daten enthält, ist ja egal. Wenn ich 512 Byte Blöcke
hab, sollten 5 Byte genausoschnell geschrieben werden, wie 515.
Kann man natürlich durch geschickte Datenanordnung ausnutzen. Zum
Beispiel in dem man einen Index macht usw, klar.

> > Die DB weiß vielleicht noch, daß von dem 16KB Block nur die
> > ersten 20 Byte ein neu zu speichernder int ist. Auf eine RAW
> > Partition schreibt sie daher vielleicht nur die ersten 4KB,
> > weil das die unterliegenden Blockgröße ist (die man kennen
> > sollte). Bekommt ein JFS 16KB,
> 
> Die DB schreibt also die ersten 20 Byte und das Filesystem
> macht dann das beste draus. Es schreibt einen Plattenblock
> (512byte) wenn es schlau ist oder  einen zb. 4k-FS-Block, wenn
> es unschlau ist. Also wähle man ein schlaues FS.

Also, ein Plattenblock ist gern mal 4K bis 64K groß, oder? Wenn
das FS einen Schreibrequest über 4KB bekommt, MUSS es 4KB
schreiben (oder gar nix). Es weiß ja nicht, welche 20Byte davon
"benutzt" sind. Es sieht nur 4KB. Kostet auch 4KB Cache. Die
Datenbank weiß das aber. Sie benötigt hier nur 20 Byte cache (na
ja, klar, hinkt alles etc, aber ist ja nur ein Beispiel). Das
führt also dazu, daß die Datenbank die 20 Byte überhaupt gar
nicht schreibt. Die werden geschrieben, wenn ein PLattenblock
(4KB oder sowas) für's WAL voll sind. Das wird dann in einem
Zucken auf die Disk gebracht. In der WAL-Datei ist das dann
vermutlich "so ziemlich gegen Ende des Files" oder genau da, bei
einer Partiotion eben irgendwo.

> > muß es diesen Block schreiben oder nicht, darf aber nichts
> > halbes schreiben (ist ja gerade der Sinn eines JFS, atomare
> > Dateiänderungen zu haben).
> 
> Bei reiserfs bis 3.6.x hat man das per default nicht. Es hält
> lediglich sich selbst konsistent und nicht die Daten 

Na toll. Dann ist reiserfs also noch viel weniger geeignet, um
Datenbank Tablespace zu verwalten!

> (deswegen ist es auch so empfindlich).

Denke eher, daß liegt an den redundanzarmen Strukturen mit
extremen Fehlerwachstum (ein falsches Bit in einem Hash "tut mehr
weh" als ein kaputtes Bit in einer linearen Liste).


> Von daher sehe ich den Sinn des JFS eher darin, daß es immer
> ein konsistentes Filesystem gibt, also Atomare Änderung der
> Metainformationen.  

Das hielt ich immer selbst verständlich... Das eine Datei nicht
mal zwischendurch 4GB groß ist, muß eh gewährleistet sein. ext2
macht das in der Praxis auch prima. Nur nach dem crash eben
langsam, weil niemand mehr weiß, wo man nu was recovern muß :)

> Atomare Dateiänderungen halte ich mit den bisherigen
> Linux-JFSsen eher für einen Wunschtraum. Ich hatte auch schon
> mit ext3 inkonsistene/falsche Daten nach einem crash.

Würde erstmal bezweifeln, daß das an ext3 lag.

> Wenn Du eine riesenriesenriesengroße Datei schreibst in ein
> ext3, dann wird diese Datei stücklweise geschrieben und mit ihr
> die metainformation stücklweise upgedated.

Das ist schlecht. Und falsch, oder? Wenn dem so wäre, könnte man
sich das J ja gleich klemmen. Und muß sich nicht wundern, daß DBs
da nicht drauf laufen wollen.

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

> > Ein JFS muß zusätzlich aber die Datei atomar konsistent
> > halten,
> 
> na eben nicht. reiserfs 3 macht das per default nicht.

Ja, prima, also noch ein Grund, kein Filesystem zwischen zu
legen. Es hält die Daten nicht konsisten. Sprich, die Datenbank
findet vermutlich ihre Tablespace, aber was drin steht, ist mehr
oder weniger Zufall. Na toll :-)

> > Mußt Du sowieso, weil Du nie wissen kannst, wieviel Platz die
> > DB gerade von dem 2GB großen Tablespacefile verwendet. df
> > erzählt Dir zwar irgendwas, aber das hilft auch nicht mehr,
> > als fdisk...
> 
> Also hängt das wieder von der DB ab und wie sie mit Dateien umgeht.

Gehen wir davon aus, sie ist nicht-trivial und sinnvoll
implementiert. Dann wird eine DB sicherlich beim Löschen von
Records NICHT alle anderen Datensätzen umschieben, um die Datei
kleiner zu kriegen, sondern das einfach so lassen :-)

> Es gibt Datenbanken, die brauchen nur so viel Filesystem-Platz
> wie tatsächlich von Daten eingenommen wird, davon sprach ich :)

Diese müssen aber verdammt ineffizient sein. Selbst berkley-DB
und was es an File-"Datenbanken" gibt, sind schlauer und lassen
die Dateigröße so. Welche Datenbank meinst Du? Muß man immer
einen großen Bogen drum machen :-)

> > reiserfs ist z.B. bei Hardwareproblemen anfällig, hört man. Wenn
> > eine DB nun sehr geschickt arbeitet, beispielsweise mit
> > fehlerkorrigierbaren, verteilten Codes, kann eine DB ja den
> > Ausfall einzelner physikalischer Blöcke prima verkaften. Wird
> > eben ein "HotFix" Block reingenommen und dessen Daten über den
> > Code restauriert.
> 
> Klingt gut. Kann man mit einem RAID auch erreichen.

Ja, aber einen ungünstigen Bitfehler auf dem Kabel oder sowas
kann man eben nicht. Natürlich gibt es viele Punkte, wo man
Datensicherheit erhöhen kann, klar. Aber man verläßt sich nicht
drauf, wenn es "teuer" wird, also der Fehler in zu schlechtem
Verhältnis zum Schaden steht. Ein Superblock bei ext2 ist ein
schönes Beispiel. sind nur ein paar Bytes aber verdammt wichtig.
Was macht man? Man schreibt den einfach überall mal hin. Einer
wird schon überleben. Sind 5 Plattenblöcke kaputt, kann man
immernoch einen Großteil der Daten erreichen. Auch wenn man das
hoffentlich nie braucht, ist es gute Praxis, finde ich. reiser
nimmt hashes für Dateinamen. Natürlich kann man die Hashwerte
rekonstruieren, aber scheinbar gibt's hier kein Tool für.
Außerdem merkt man Datenfehler hier nicht. Natürlich ist das
meist egal, weil die Platte ja hardwaremäßig redundante Codes
verwendet, klar, aber eine Platte ewiß ja auch nicht, daß Block
12412 vielleicht 100mal wichtiger ist, als Block 13332 oder so.
Als Datenbank ist mir Block 12412 vielleicht so wichtig, daß ich
ihn als 13334 doppelt halte, weil man ja nie weiß. Wenn ein LVM
im Extremfall beide Blöcke physikalisch nebeneinander legt, hat
man zwar vermutlich Pech mit der Idee, weil beide gehen oder
beide kaputt sind, aber immerhin :)

> Also wird z.b. in Oracle ein halbes OS nachgebaut. Wozu? Ich
> seh da wirklich denn Sinn nicht.

Davon schreib ich doch schon Romane! Weil die DB seine
Datenstrukturen kennt und damit besser verwalten kann. Weil eine
DB weiß, daß Block 12412 teuer ist. Wenn die
Gesammtdatenbankkonsistenz von Block 12412 abhängt, ist es
einfach mal egal, was das Schreiben kostet: es MUSS gemacht
werden. Bei Block 13334 kann das ganz anders sein; vielleicht ist
der in Block 12412 eh als ungenutzt markiert. Kann ein Filesystem
aber nicht wissen, weil es den Inhalt von Block 12412 doch nicht
verstehen kann! Es sieht nur zwei Blöcke und muß die gleich
behandeln!

> Das drunterligende OS (egal welches) kann doch schon so vieles.

Aber eben nicht ideal. Ein OS kann die Logik ja nicht umgehen :-)

> > Wenn eine DB auf einem LVM arbeitet, findet sie natürlich ihre
> > Daten, logisch, fragt sich bloß, welchen Vorteil es bringt,
> > RAW-Devices über LVM zu verwenden :-)
> 
> Man kann sie beliebig verschieben :)

Wie schon gesagt, daß kann man eh, also braucht man kein LVM. Ein
LVM muß dann auch die Bereiche verschieben, die zwar in einer
Datei liegen, aber nicht verwendet werden, beispielsweise, weil
es nur unbenutzte (gelöschte) Records enthält. Damit macht das OS
also auch diesen Fall maximal so gut wie die DB, die DB aber in
vielen Fällen effizienter. Wenn man I/O spart, ist man besser.
Dazu muß man eben wissen, wo man sparen kann. Ist doch logisch.
Ein Filesystem kann das nicht wissen. Es sieht eine große Datei.
Es versteht die Semantik nicht, weiß also nicht, welche Bereiche
"egal" sind. Ein DB weiß das aber. Aber das ist wieder nur
Performance, also find ich das persönlich weniger interessant.
:-)

oki,

Steffen

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