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

[Ihno Krumreich]

On Fri, Aug 15, 2003 at 06:01:48AM +0200, Jan Krueger wrote:
> 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.
> 
> > 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.

Es ist egal, ob man bei einem Schreibauftrag 512 (blockgroesse der
Platte) oder 4096 (meistens die Groesse einer Page) schreiben will.
Die differenz an Rechenzeit fuer die beiden Auftraege ist akademischer
Natur und wahrscheinlich noch nicht mal messbar. Der Rechenaufwand liegt
im Verwalten des Auftrages. 

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

Nur 20 Byte zu schreiben ist die VERSCHWENDUNG. Der DB-Cache hat die
Aufgabe die IO zu minimieren. Schreibt man nur 20 Byte, dann muss das
Dateisystem (oder auch das BLocklayer-System, denn 20 Byte kann man auch
auf einem raw-device schreiben) diese Bytes in den Block fummelm und
dann den ganzen Block schreiben. Ergebnis ist das ein ganzer Block
geschrieben wird. Das kann das DB-System dann auch gleich selbst machen.

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

Die Transaktionsverwaltung in DB-System ist ein ziemlich komplexer und
schwieriger Bereich. Anfang und Ende einer Transaktion werden vom
Programmierer/Nutzer definert und koennen im Extremfall bis zu mehreren
Stunden dauern. Das Ueberlagern zweier Transaktionssystem mit
unterschiedlicher Semantik erhoeht nicht die Zuverlaessigkeit.
Insbesondere wenn das eine Transaktionssystem nur Metadaten
beuecksichtigt.

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

Das Nachbauen von teilen des OS hat Oracle mit vielen anderen DBs
gemeinsam. Das Problem liegt in dem Ziel die IO insgesammt zu minimieren
UND Transaktionen zu machen. Transaktionen erfordern IO um den Zustand
auf die Platte zu schreiben. IO will man aber nicht, da einen dies von
anderen Dingen abhaelt (The best IO is no IO). Das
"Hintereinanderschalten" zweier Caches (DB und OS Cache) bringt nichts,
da man den Speicher dann besser dem DB-System spendiert. Im schlimmsten
Fall behindern sich die beiden Caches, weil unter Umstaenden im zweiten
Cache immer genau das ist was der erste nicht braucht. Ein Zugriff auf
den zweiten Cache resultiert damit immer in einer "Echten" IO. D.h.
der zweite Cache ist praktisch nicht da. Das ist wohl einer der
Hauptgruende warum DB-Systeme direkte IO machen wollen.

Ihno