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

[Steffen Dettmer]

* Jan Krueger wrote on Thu, Aug 14, 2003 at 17:54 +0200:
> On Wednesday 13 August 2003 23:11, Steffen Dettmer wrote:
> > * Dani Oderbolz wrote on Wed, Aug 13, 2003 at 13:29 +0200:
> > > (Man machte es nur aus Performance Gründen).
> >
> > Das bezweifel ich!
> 
> Ein Journaling FS loggt in der Regel nur Metainformationen
> (Wieviel genau und wo das hin soll und mit welchen attributen)
> nicht die Daten selbst. Eine DB loggt in der Regel die Daten.

Meinst Du log oder lock? 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 ;)

Eine DB schreibt ja Änderungen gern mal als WAL oder sowas, also
irgendwie inkrementell, was auch bei Backups ganz nett sein kann.
Was da drin steht, muß man auf Platte haben; wenn ein JFS die
Änderungen der Datei rollback'd, kann das doof sein, wenn die
Datenbank gerade was sehr wichtiges geschrieben hat. Da ein JFS
ja schlecht die Abhängigkeiten zwischen den einzelnen Files
kennen kann, könnte ich mir sogar vorstellen, daß zwar jedes
einzele File atomar sicher ist, aber nicht alle Files zusammen
atomar sind (weil File A schon geschrieben wurde, B aber noch
nicht). Kann auch wieder zu Inkonsistenzen führen. Die DB kann
natürlich in File A vermerken, wie der Stand von B war, aber nur,
wenn gerantiert ist, das A erst nach B geschrieben wird - was ein
JFS aber nicht macht.

> Informationen loggt. Bei der vor einiger Zeit erwähnten
> Objektorientierten DB geschah das loggen durch anlegen einer
> einzelnen Datei für jede Transaktion, 

Na, wenn man das so implementiert, redet man vermutlich weder
über Performance noch über Sicherheit, sondern über eine schnelle
Implementierung :-)

Ich denk, logischer für ne Datenbank wäre was in der Art von
mmap.

> also muß das Filesystem auch jedesmal die Metainformationen
> loggen -> performance geht runter. 

Nee, kann das JFS ja über'n Speicher machen (und wird das
sicherlich auch machen). Hier sehe ich keine Probleme - es sei
denn, die 128 Bit sind ein wichtiger Transaktionszähler oder
sowas, die mit den anderen Dateien konsistent sein müssen.

> Wenn die DB nun aber schlau ist, und so loggt (eine ausreichend
> große Datei für alles, die größe der datei ändert sich nicht),
> daß das Filesystem nicht ständig Metainfos schreiben muß, wird
> man kaum einen Unterschied feststellen können zwischen
> Partition Direkt und Filesystem.

Eben, man macht das ja auch nicht aus Performancegründen. Gut,
ein JFS schreibt nie weniger aber eventuell mehr Daten, kann also
nie besser als eine DB sein, aber in der Praxis schreiben
Datenbanken sicherlich eh Blockweise, so daß der Unterschied
nicht auffallen sollte (von DBMSes mal abgesehen, die 128 bit
Dateien erzeugen ;-)).

> Es kommt also auf die DB an und wie sie loggt.

Natürlich kann man eine DB schreiben, die über RAW schlechter
ist, als über Files, beispielsweise, wenn RAW überhaupt nicht
gecacht wird, klar.

> Man kann Software so schreiben, daß sie die Features eines OS
> optimal für sich nutzt oder man läßt es und geht davon aus,
> sämtliche OSse sind eh nur aus Pappe und man selbst kann man
> sowieso alles viiieeel besser und macht halt alles selbst.

Mit der Datenabstraktion tritt logischerweise auch ein
Informationsverlust auf. 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, muß es diesen Block
schreiben oder nicht, darf aber nichts halbes schreiben (ist ja
gerade der Sinn eines JFS, atomare Dateiänderungen zu haben). Da
schreibt man hier also im Extremfall 12KB zu viel. Wenn die 16KB
in sowas wie einem Write-Ahead-log sind, haben die Blöcke
vielleicht sogar ein dirty-Flag, so daß es egal ist, ob nu alle
Blöcke des WAL oder nur die ersten n korrekt sind (hauptsache,
Blockweise atomar). Ist natürlich prima, muß man nur der Reihe
nach wegschreiben. unbelegte Blöcke als dirty kann man markieren,
wenn eh gerade Zeit ist oder man einen neuen Tablespace erzeugt,
also "irgendwann". Ein JFS muß zusätzlich aber die Datei atomar
konsistent halten, und dies noch in einem
Meta-Informationsverzeichnis speichern. Eine ideale DB
vorrausgesetzt, kann das JFS also maximal gleich gut sein, jedoch
nie besser. Wenn man eine (1) WAL-Datei hat, reicht JFS auch aus,
um die Konsistenz zu gewärleisten, klar. Aber auch hier kann das
JFS maximal gleich gut, aber nie besser sein (es ist ja
schlechter, wenn es beispielsweise mehrere abhängige Dateien
gibt).

> Meiner administrativen Ansicht nach, ist dieser DirectIO kram
> komplett Pappe  weil man dadurch als Administrator sehr viele
> Möglichkeiten ( positiven :) Einfluß nehmen zu können verliert.

Versteh ich nicht.

> Das fängt bei der Überwachung der Platznutzung an. Ein df ist
> mir viel sympatischer als dafür extra eine Anfrage an die DB
> stellen zu müssen.  

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

> Und hört spätestens bei irgendwelchen Defekten auf. da ist eine
> Datei doch viel einfacher zu handhaben als eine Partition mit
> binärem Krust, besonders wenn der drunterliegende Storage sich
> fehlerhaft verhält. 

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. Weiß nicht, ob das DBs in der Praxis machen,
aber sowas gibt es bestimmt. Wenn aber die Datei weg ist, weil
das JFS sowas eben nicht macht, ist's essig. Dann nützt einem der
schöne fehlertolerante Code gar nix, weil durch den Verlust eines
einzigen Blockes (der die Hashtabelle des Filesystems hatte)
plötzlich das gesammte File - also alle Blöcke - "verloren"
sind....

> Die Datei kommt einfach woanders hin, und die Partition? Wenn
> man die Partition bewegt (mit LVM oder so), findet die DB noch
> ihre Daten?

Weiß nicht, ob man über LVM RAW-Partitionen machen kann. Eine DB,
die Partionen schreiben kann, kann Tablespaces sicherlich auch
verschieben. Bin mir recht sicher, daß man bei Oracle Tablespaces
wieder entfernen kann. Dauert dann natürlich, müssen schließlich
erst freigeschaufelt werden, aber geht. Ne DB hat ja ein "LVM
eingebaut", man kann auch ohne LVM Tabellen über verschiedene
Partionen verteilen (bin mir auch recht sicher, daß Oracle das
kann, und vermutlich striped die dann auch gleich etc. pp).

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

oki,

Steffen

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