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

[Jan Krueger]

On Friday 15 August 2003 00:57, Steffen Dettmer wrote:
> * Jan Krueger wrote on Thu, Aug 14, 2003 at 17:54 +0200:
> > 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 ;)

(ersetzen wir oben "in der Regel" durch "manchmal, je nach implementation" :)

Eben. Crash, Du sagst es ja. Müssen muß sie nicht, aber können kann es die 
eine oder andere. Damit die Daten und Informationen über die Transaktion im 
Zweifelsfalls nicht verloren gehen, werden Sie außerhalb der DB geloggt. 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. Also auch nach dem crash 
oder nach lock-freigabe könnten Sie recovered/eingefügt werden.

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

Ja, den Eindruck könnte man gewinnen :)

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

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.

> Eben, man macht das ja auch nicht aus Performancegründen.

Na aber warum denn dann?

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

Jain. Die erwähnte Objektorientierte Datenbank hat sich an pages orientiert 
und glaubte dadurch sehr schnell zu sein. Das war sie auch, bei Daten die gut 
in pages passen :) ansonsten führte es eher zu IO-Verschwendung.

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

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.

> 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 (deswegen ist es auch so empfindlich). 
bei ext3 kann man mit data=writeback den Daten kein Gewicht beimessen, das 
Filesystem wird weiterhin konsistent gehalten.
Von daher sehe ich den Sinn des JFS eher darin, daß es immer ein konsistentes 
Filesystem gibt, also Atomare Änderung der Metainformationen. 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. 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. 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)

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

na eben nicht. reiserfs 3 macht das per default nicht.

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

macht nix :), ich auch nicht mehr, wenn ich so drüber nachdenk...
Auch eine Partition ist nur eine Datei ;)

# dd if=/dev/partition of=Datei 

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

Also hängt das wieder von der DB ab und wie sie mit Dateien umgeht.
Es gibt Datenbanken, die brauchen nur so viel Filesystem-Platz wie tatsächlich 
von Daten eingenommen wird, davon sprach ich :)

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

Klingt gut. Kann man mit einem RAID auch erreichen.

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

Also wird z.b. in Oracle ein halbes OS nachgebaut. Wozu? Ich seh da wirklich 
denn Sinn nicht. Das drunterligende OS (egal welches) kann doch schon so 
vieles. Wazu also ein halbes OS nochmal nachbauen? Damit man "DirectIO" oder 
"RawIO" auf die Verpackung schreiben kann?

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

Gruß
Jan