[linux-l] FreeBSD und Linux (war: smfs 2GB )

[Jan Krueger]

On Friday 05 September 2003 00:24, Peter Ross wrote:
> > > Ein Verhaeltnis von fast 1:4 klingt allerdings nicht gut, da muss noch
> > > etwas klemmen, denke ich.
Habs herausgefunden woran es liegt. Das ist erwartetes Verhalten von 
softupdates -> benchmarkfehler!

Bei *BSD Softupdates werden schreib-request in einem Puffer gepuffert und dann 
die passenden zusammengebündelt und schnell auf Platte geschrieben (sofern 
überhaupt noch notwendig). Die Anzahl der wirklich notwendigen 
Schreibzugriffe wird durch softupdates stark minimiert. Es kann relativ lange 
und effektiv gepuffert werden wenn viele von einander unabhängige 
schreibrequests eintrudeln und ohne die konsistenz des filesystems zu 
beeinträchtigen.
(Wer sich das genauer anschauen möchte kann dies unter:
http://www.mckusick.com/softdep/index.html tun)
Das funktioniert erstaunlich gut, solange die requests nicht voneinander 
abhängig sind, also zb. im normalen Worstation oder Serverbetrieb. 
(verschiedene prozesse schreiben in verschiedene Dateien)

Wenn jetzt aber mysql sql-bench daherkommt und 10000 inserts nacheinander 
ausführen will, tut mysql genau das was ihm gesagt wird, ein insert nach dem 
anderen und jedes mal sicherstellen, daß der vorige insert auch schon in der 
db ist (mit fsync oder so). Dadurch entsteht eine sequenz von voneinander 
abhängigen Schreib-requests und der softupdates puffer bringt gar nix, außer 
einer klitzekleinen verzögerung, weil das schreiben der requests nicht 
optimiert werden kann. Das bedeutet die Performance von Softupdates 
degradiert in diesem Fall zu der performance eines synchronen Filesystems.

Linux 2.6 hingegen nimmt das mit dem synchron nicht wirklich richtig ernst, so 
wie alle linuxe vorher auch schon, und erreicht dadurch und durch den 
Disk-scheduler/elevator und durch advanced reiserfs eine derart hohe 
performance.

Im normalen arbeitsfall (workstation oder server) verspricht Softupdates ein 
besseres Verhalten (kann ich bis jetzt auch bestätigen) , weil es die anzahl 
der notwendigen schreibzugriffe effektiv reduziert.

Bei linux werden die Zugriffe plattengerecht umgeordnet (durch den 
disk-scheduler/elevator) und die tatsächlich notwendigen Zugriffe werden 
durch simples warten (bei ext3 commit intervall) und puffern gebündelt und 
damit reduziert. Weit weniger optimal als softupdates das können. hinzu 
kommt: ein log für das jfs muß geschrieben werden, also gegenüber softupdates 
weiter eine leichte erhöhung der Anzahl der Zugriffe.
Hier läßt sich auch erkennen, warum linux 2.6 im sql-bench besser performt:
Es puffert, warted das commit intervall ab (soweit es halt geht) und gewinnt 
jetzt besonders durch das durch den warte-puffer mögliche plattenoptimierte 
umordnen (disk scheduler/elevator) der requests, während softupdates an 
dieser stelle einfach synchron werden.
Ich hoffe es läßt sich erkennen, auch wenn linux in benchmarks besser 
performt, daß das verhalten von linux, meiner Ansicht nach, suboptimal ist.
Wenn sich das nur in benchmarks wiederspiegeln würde ...
Ich muß wohl noch nach dem richtigen benchmark suchen :)

Gruß
Jan