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

[Jan Krueger]

On Wednesday 13 August 2003 23:11, Steffen Dettmer wrote:
> * Dani Oderbolz wrote on Wed, Aug 13, 2003 at 13:29 +0200:
> > Das problemist, dass das ganez sehr schwer zu handeln ist (Du
> > kannst halt nicht einfach kucken, wo welche Daten liegen, es
> > ist eine Mega - Blackbox.
>
> Geht bei Tablespaces ohnehin schlecht. Und sollte einen auch
> nicht wirklich interessieren, was da binär rumliegt, oder?
>
> > (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. Ein JFS und eine DB ergänzen sich also 
wunderbar :)

Gegenüber dem DB-Schreiben direkt auf die Partition entsteht beim JFS ein 
Overhead für des Schreiben der MetaInformationen. Besonders bei vielen 
kleinen Transaktionen kann sich das ausbremsend bemerkmar machen, abhängig 
davon, wie die DB die Informationen loggt. Bei der vor einiger Zeit erwähnten 
Objektorientierten DB geschah das loggen durch anlegen einer einzelnen Datei 
für jede Transaktion, also muß das Filesystem auch jedesmal die 
Metainformationen loggen -> performance geht runter. Krass wird es natürlich, 
wenn dann die geloggten Daten winzig sind, sagen wir 128 Bit, dann wird 
deutlich, da die Metainformation größer ist als die Daten, daß ein JFS 
ausbremst.

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.

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

> > Das Problem das du ansprichst ist mit Journaling FS eigentlich
> > gut gelöst - obwohl du damit natürlich 2 Mal loggst.

s.o.

> Das JFS kann ja nicht wissen, welche 100KB von den 2GB unbedingt
> synchron geschrieben werden muß (koste es, was es wolle), kann
> also nie optimal synchronisieren. Und ganz ohne caching geht kein
> Filesystem unter Linux, weil die unteren Ebenen AFAIK schon einen
> Buffercache bereitstellen. Was man hier aber eben nicht möchte.
> Die DB möchte an ein paar Stellen das genau wissen, und nur die
> DB kennt die Semantik der binärdaten. Cachen muß eine DB sowieso,
> also bringt das Buffer-Caching nicht so viel, verbraucht bloß
> Speicher und cacht dann notfalls vollständig Blöcke, die
> vielleicht nur zum Teil belegt sind etc.

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.

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.
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.
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. Die Datei kommt 
einfach woanders hin, und die Partition? Wenn man die Partition bewegt (mit 
LVM oder so), findet die DB noch ihre Daten?

Gruß
Jan