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

[Peter Ross]

On Mon, 8 Sep 2003, Jan Krueger wrote:

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

Tja, Benchmarks testen immer nur das, was sie genau tun. Daraus
Schlussfolgerungen zu ziehen, ist oft nur sehr schwer moeglich.

> (Wer sich das genauer anschauen möchte kann dies unter:
> http://www.mckusick.com/softdep/index.html tun)

Die dahinterstehende Logik ist nach meinem Empfinden wirklich schwer zu
implementieren, so dass es erstaunlich ist, wie wenig es bei der
Einfuehrung in den Produktionszweig "gekracht" hat. Trotz langem Testen
hat es da kurz Probleme gegeben, allerdings fuer ganz wenige Anwender, und
der Fix in einer Subrelease (4.5.1 oder 4.6.1, weiss ich nicht mehr) war
sehr schnell draussen.

Ein Stueck Software, was ich mich nie trauen wuerde zu schreiben;-) Hut
ab!

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

"Suboptimal".. hmmh. Ich weiss nicht, ob ich Dich richtig verstanden
habe.. heisst das: Der "disk scheduler/elevator" optimiert durch weiteres
Caching auf physischer Ebene?

Es klingt fuer mich geradezu gefaehrlich, wenn es bedeuten wuerde, dass es
Aenderungen nicht wirklich durchreicht, sondern drueberliegenden Ebenen
nur ein "Okay" gibt, ohne wirklich zu schreiben. Strom weg - Daten weg?

Softupdates schreibt meines Wissens wirklich, wenn ich ein sync will (das
scheint Dein Test auch zu bestaetigen)

> Wenn sich das nur in benchmarks wiederspiegeln würde ...
> Ich muß wohl noch nach dem richtigen benchmark suchen :)

Wenn ich Dich richtig verstanden habe, wirst Du den Benchmark nicht finden
- wenn die Implementation unsauber arbeitet, um die Performance zu
erhoehen, dann erhoeht sie halt die Performance auf Kosten der
Datensicherheit.

Es sei denn, Du kannst dieses puffernde Verhalten des disk elevators
abschalten?

Was dann ganz am besten fett irgendwo stehen sollte - z.B. als letzte
Meldung der MySQL-Installation. Man kann ja nicht alles wissen;-)

Gruss
Peter