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

[Jan Krueger]

On Monday 08 September 2003 01:05, Peter Ross wrote:
> 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!
Ja. Wenn man die Linux-dingse zusammen betrachtet:
buffer-cache, page-cache
logging-filesystem
disk-scheduler/elevator
dann glaub ich sind softupdates im Vorteil :)

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

Nicht wirklich. Der puffer ist ja schon da. der "disk scheduler/elevator" bei 
seinem weg über die plattenoberfläche holt sich halt das aus dem puffer 
was bei ihm gerade sowieso auf dem weg liegt. dabei muß natürlich auch er die 
abhängigkeiten, die spätestens durch das filesystem und sein logging und 
metadatenschreiben festgelegt werden, beachten. Da grundsätzlich erstmal 
alles gepuffert wird, und somit nur die reihenfolge der voneinander 
abhängigen dinge beachtet werden muß und zusätzlich noch etwas zeit vergehen 
darf(das ist der entscheidende punkt der das umordnen erst möglich macht), 
gelingt das umordnen ganz gut. Ist halt keineswegs synchron.

> 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?
Ja, ich denke die Annahme ist hier, daß wenn der Strom ausfällt, der 
eigentliche Zeitpunkt egal ist. Daten gehen so oder so verloren, ob es nun 2 
millisekunden eher passiert oder nicht. Von daher kann man in den 2 
millisekunden auch paar megabyte cachen, erhöht die performance merklich, und 
beim stromausfall sind so oder so daten weg, die paar gecachten megabyte 
spielen da keine Rolle mehr. So stelle ich mir die Annahme vor. Funktioniert 
ja trotzdem ganz gut das Linux. Ein jfs bleibt trotz stromausfall konsistent. 
lediglich paar megabyte fehlen im zweifelsfall, es läßt sich aber nicht 
wirklich feststellen ob die anwendung sie schon als gebucht vermerkt hatte 
oder nicht, weil ja stromausfall war und alle speicherinformationen damit 
gelöscht.  Also egal. Es sei denn, siehe beispiel unten, ein weiteres system 
kommt ins spiel.

> Softupdates schreibt meines Wissens wirklich, wenn ich ein sync will (das
> scheint Dein Test auch zu bestaetigen)
Nicht wirklich, auch bei softupdates wird gepuffert um ein umordnen zu 
ermöglichen und damit das synchrone schreiben verhindert. Das quasi synchrone 
schreiben im benchmark ergibt sich daraus, daß der puffer volläuft und 
trotzdem kein umordnen möglich ist, daher werden die schreibanfragen schön 
nacheinander auf platte, also wie bei einem synchronen filesystem, 
geschrieben. write data, write metadata, write data, write metadata, usw. ..
für jeden insert, das dauert ... die notwendigen schreibbarrieren, welche die 
ordentliche reihenfolge garantieren, also nach jedem mini insert, lassen sich 
halt so nicht weiter auflösen.

der scheduler von linux kann, durch das kleine zusätzliche Zeitfenster, nun 
mehrere write datas, write metadatas zusammenfassen, plattengerecht 
aufbereiten ohne die reihenfolge zu mißachten und in einem wusch auf die 
platte rubbeln :)
die schreibarrieren werden eingehalten.

> > 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.
Ja, nur scheint dieses kleine Fenster der Datenunsicherheit durchaus 
akzeptierbar zu sein. Vorhin hat mein Linx-2.6.0-test4-bk8 einfach mal einen 
spontanen spontanreboot hingelegt, ganz spontan. puff und weg. (Der 
sound-treiber ist schuld, kenn das schon inzwischen, war nicht das erste mal, 
aber jedesmal ist irgenwie anders, gestern hat mein linux auf einmal komische 
geräusche im loop gemacht, wie technomusik, keine ahnung wo es das her 
hatte.) Jedenfalls war die mail an der ich grad schrieb weg, klar, trotzdem 
fuhr es supersauber wieder hoch ohne einen muks zu machen.
Also, für mich ist diese kleine unsicherheits Fenster akzeptierbar soweit, und 
war es auch immer bisher. Anders sähe es aus, wenn ich auf save geklickt 
hätte und nach dem neustart wäre meine mail weg gewesen, das hätte mich 
geärgert, aber auch sowas ist mir bisher mit 2.6 nicht passiert, also scheint 
dieses unsicherheitsfenster wirklich klein genug zu sein um nicht zu sehr 
daten zu vermurksen und andererseits groß genug um die performance merkbar zu 
erhöhen.

> Es sei denn, Du kannst dieses puffernde Verhalten des disk elevators
> abschalten?
Ich glaub da gibts ne kernel option oder eine make config option in der 
2.6.bla-mm serie, ich weiß nicht genau.

> Was dann ganz am besten fett irgendwo stehen sollte - z.B. als letzte
> Meldung der MySQL-Installation. Man kann ja nicht alles wissen;-)
djb bemerkt diesen aspekt der linux filesysteme ja auf seinen qmail seiten.
Sprich im zweifelsfall war der empfang einer mail bestätigt, die mail aber 
noch nicht wirklich auf platte geschrieben worden. Hm. Muß der User, 
Administrator oder einer seiner chefs entscheiden ob das akzeptierbar ist.

djb behaupted man soll das linux fs mit der sync option mounten damit dieses 
problem nicht auftritt. Ich glaub da nicht so wirklich dran wenn ich mir zum 
beispiel reiserfs anschaue. bei ext3 mag das noch gehen.
(http://cr.yp.to/qmail/faq/reliability.html#filesystems)

Er sagt auch, softupdates soll man nicht verwenden. klar, auch hier wird durch 
das puffern und umordnen das zeitgetreue erscheinen der daten auf der platte 
verhindert. 

So oder so, ein tradeoff zwischen sicherheit und performance.
Vielleicht kann man das softupdate verhalten noch optimieren wenn man noch 
einen gescheiten disk-scheduler drunterpackt, wobei mir das auch irgendwie 
überflüssig erscheint. naja, ich werd das mal noch weiter untersuchen.

Gruß
Jan