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

Jan Krueger jk at microgalaxy.net
Sa Aug 16 20:22:15 CEST 2003


On Friday 15 August 2003 16:49, Jan Krueger wrote:
> On Friday 15 August 2003 06:56, Ihno Krumreich wrote:
> > 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
>
> Aha, also kann man zusammenfassend sagen:
> Es gab und gibt bis heute kein wirklich datenbanktaugliches Betriebssystem.
> Als workaround verwendet man DirectIO oder RawIO.
> schade eigentlich.

Völliger Quatsch. Alles was man benötigt um radioaktive ( =atomare :) 
transaktionssicherheit hinzubekommen ist die garantie vom OS daß nacheinander 
folgende Schreibvorgänge auch wirklich in der ursprünglichen Reihenfolge 
ausgeführt werden UND daß wenn ein Vorgang als geschrieben gilt, die Daten 
auch wirklich auf Platte sind. Folglich benötigt man nicht mal ein JFS, ein 
ext2, UFS reicht vollkommen aus, zusammen mit der mount-option sync. Damit 
gibt es keinen geschwindigkeitsunterschied zwischen DirectIO und FS IO mehr.
Die radioaktivität läßt sich wunderbar auch im Userspace abbilden, wenn das 
drunterliegende OS oben genannte garantien geben kann.
Linux bis einschließlich 2.4 kann diese Garantien leider nicht geben, da es 
immer irgendwie ein bißchen async und unordered schreibt, also benötigt man 
bei Linux 2.4 DirectIO. Wie ist es mit 2.6?
Die *BSDs hingegen meines halbwissens nach, schreiben dann wirklich synchron 
und würden obige Anforderungen erfüllen.

Bleibt das caching, und dies kann man mit open und der Option O_DIRECT 
größtenteils umgehen. bei mmap wirds schwieriger. Da sind die Fragen:
Was cachen DBs? Wie cachen DBs?
Die DB mag eine andere Vorstellung davon haben, wie lang bestimmte Daten 
gecached sein sollten, zb. Das kann man ja leider vom userspace nicht direkt 
steuern. Hm , schade. DiectIO benutzen? oder den OS cache nutzen für alle 
anderen Daten und Vorgänge, und für bestimmte Daten und Vorgänge, die halt 
gesondert behandelt werden müsse, weil sie zb. regelmäßig immer wieder 
abgefragt werden und nur die DB das weiß und der speicher dafür da ist, einen 
2 cache einführen, welcher lediglich diese besonderen gegebenheiten abbildet?

> "Everything is a file" scheint vor diesem hintergrund doch überholt.

Nö, gar nicht, paßt doch wunderbar.

> "Everything is can be a atomic datum" manchmal wünschenswert.

Läßt sich auch prima mit "Everything is a file" abbilden.
(zb. schreibe file mit daten, schreibe file mit metainformationen, schreibe 
file mit bitmap in welchem man genau 1 bit ändert welches vorher geschriebene 
daten für gültig erklärt. Änderung eines bits ist immer radioaktiv, also 
atomar :)(kann auch alles in einem file sein)


> Danke für Eure Erklärungen. DirectIO ist derzeit also wirklich eine
> Notwendigkeit für richtige Datenbanken.

Direct IO ist nicht notwendig, außer bei Linux :)

> Datenbanken die kein DirectIO
> verwenden sind nicht wirklich als "Datenbanken" zu bezeichnen, eher als
> "Daten-Sammelbecken mit Abfragemechanismus" oder so ähnlich :)

MySQL ist eine tolle Datenbank genau wie PostgreSQL.

Oracle mit DirectIO auf shared disks ist totaler humbug. benötigt beinahe 
unendlich viel ressourcen, ist aufwändig zu managen, superteuer, nicht 
schneller (Partner müssen sich PlattenIO teilen)(außer bei CPU intensiven 
Abfragen die wenig IO benötigen [hier wär ordentlich SMP billiger]) und auch 
nicht sicherer (baut ein Partner Mist mit den Daten ist der 2. genauso davon 
betroffen). 

> Gruß
> Jan
bekräftige ich noch einmal mit einem unbreakable
Gruß
Jan





Mehr Informationen über die Mailingliste linux-l