Kernel 2.6 Filesystem-buffer snel gevuld

[XTerm]

Ik heb iets raars gemerkt met Linux 2.6.8.1:

Als je bijvoorbeeld "cat /dev/hda > /dev/null" doet moet je eens kijken wat er met je buffers gebeurt. Op mijn systeem (op 3 geprobeerd) loopt deze gewoon knalvol.
Het zelfde commando op een 2.4 kernel doet helemaal niets met de buffers.

Ik heb dit opgemerkt toen iemand wat grote shit van m'n ftp haalde en m'n geheugen volliep. Kan iemand dit gedrag verifieeren ?

[MTWZZ]

Komt dit niet gewoon omdat je hd xs in je geheugen gebufferd wordt??
Aannemende dat je met buffers die bedoeld in "free -omt".

[irondog]

XTerm schreef op 12 oktober 2004 @ 17:46:
Ik heb iets raars gemerkt met Linux 2.6.8.1:

O ja, vertel?

Als je bijvoorbeeld "cat /dev/hda > /dev/null" doet moet je eens kijken wat er met je buffers gebeurt. Op mijn systeem (op 3 geprobeerd) loopt deze gewoon knalvol.
Het zelfde commando op een 2.4 kernel doet helemaal niets met de buffers.

Tja een typisch voorbeeld van een bufferoverflow. Ik zou je exploit maar meteen posten op www.securiteam.com

Maar dat was dus even onzin. Wat je zou moeten doen nadat je "cat /dev/hda > /dev/null" doet, is allerlei zware programma's opstarten. Begin maar eens met openoffice, daarna lanceer je een game als ut2004 of doom3 en kijk dan maar eens wat er met die buffers gebeurt.

Trouwens, let even op dit:

code:

             total       used       free     shared    buffers     cached
Mem:       1034756    1029424       5332          0     471048     315924
-/+ buffers/cache:     242452     792304
Swap:            0          0          0

Total=used+free en die buffers worden overschreven zodra de kernel dat nodig acht. Dus het kost je geen vrij geheugen ofzo!!

Wat ook leuk is om te doen is dit (op een vers opgestarte desktop):

code:

time dd if=/dev/hda of=/dev/null bs=1k count=128k
time dd if=/dev/hda of=/dev/null bs=1k count=128k

De tweede keer zul je zien dat de benchmark onvoorstelbaar snel klaar is, tenminste bij kernel 2.6. Dat komt omdat je de tweede keer eigenlijk eerder je geheugen bencht, dan je harddisk

[Bergen]

irondog schreef op 12 oktober 2004 @ 19:47:
[...]

Wat ook leuk is om te doen is dit (op een vers opgestarte desktop):

code:

time dd if=/dev/hda of=/dev/null bs=1k count=128k
time dd if=/dev/hda of=/dev/null bs=1k count=128k

De tweede keer zul je zien dat de benchmark onvoorstelbaar snel klaar is, tenminste bij kernel 2.6. Dat komt omdat je de tweede keer eigenlijk eerder je geheugen bencht, dan je harddisk

Maar de derde keer gaat het nog sneller en de vierde keer nog sneller etc.:

134217728 bytes transferred in 3.155371 seconds (42536276 bytes/sec)
134217728 bytes transferred in 1.728325 seconds (77657693 bytes/sec)
134217728 bytes transferred in 1.393593 seconds (96310560 bytes/sec)
134217728 bytes transferred in 0.843534 seconds (159113596 bytes/sec)
134217728 bytes transferred in 0.792332 seconds (169395827 bytes/sec)
134217728 bytes transferred in 0.471905 seconds (284416888 bytes/sec)

Hoe verklaar je dat dan? Is 't niet gewoon zo dat hij het de eerste keer helemaal in 't geheugen zet en de tweede keer het geheugen bencht, en dat het resultaat de daarop volgende keren hetzelfde zou moeten zijn?

[_JGC_]

Buffer overflow kan ik het niet noemen.

Linux 2.6 is enorm agressief als het op cachen aan komt, je bent in principe dus gewoon je cache aan't opvullen met deze actie.

Ik heb het even op mijn P2 366 met 192MB geheugen uitgeprobeerd terwijl dat ding aan het compileren was. Alles ging gewoon zn rustige gangetje door, buffers werden tot het maximum opgevuld, maar er waren geen rare dingen te zien, mn swap verbruik bleef ook gewoon constant.

[igmar]

XTerm schreef op 12 oktober 2004 @ 17:46:
Het zelfde commando op een 2.4 kernel doet helemaal niets met de buffers.

Is dat verder relevant dan ? Je loopt nu appels met peren te vergelijken, het MM in 2.4 is niet te vergelijken met 2.6.

[Bergen]

Misschien een domme vraag hoor, maar wat is eigenlijk het probleem? De buffers lopen vol, maar ze worden toch meteen weer vrijgegeven en zijn toch meteen beschikbaar voor andere processen?

[ Voor 1% gewijzigd door Bergen op 12-10-2004 21:51 . Reden: typo ]

[Verwijderd]

Bergen schreef op 12 oktober 2004 @ 20:20:
Hoe verklaar je dat dan? Is 't niet gewoon zo dat hij het de eerste keer helemaal in 't geheugen zet en de tweede keer het geheugen bencht, en dat het resultaat de daarop volgende keren hetzelfde zou moeten zijn?

Je leeft in een multi-process OS. Je buffer is niet het enige progje dat runt, en andere progjes overschrijven dus ook weer geheugen vrijgegeven door je buffer (wat vanaf dat moment dus cache is). Je gaat dan naar een logaritmische optimaal toe.

En voor XTerm: als het goed is zal, als je geheugen vol zit, je computer een halve minuut haperen en daarna zal de OOM het proces afgeschoten hebben. Ik heb op 2.6.x al eens met soortgelijke testjes gespeeld, maar heb nog geen werkelijke fout kunnen ontdekken. Of dit nou optimaal is, vraag ik me ook af, maar aangezien ik geen expert ben in scheduling of VM laat ik dat maar in het midden...

[blaataaps]

Ik heb even de topictitel aangepast, bij mijn weten is er namelijk nergens sprake van een "overflow" van die buffer, hij wordt alleen vrij snel gevuld, wat een goed ding kan zijn

[XTerm]

Overflow is inderdaad niet meteen het juiste woord. Voor de mensen die denken dat ik niet waat wat cache is, jullie zitten ernaast

Ik wou gewoon op het verschil wijzen tussen 2.4 en 2.6. Want mijn 2.6 systeem freezed gewoon als de buffers volzitten, anders had ik het nooit opgemerkt. Nu heb ik wat lopen rondkloten en gemerkt dat het freezen niet echt iets met grote buffers te maken heeft maar met brakke X en drm