RAM-Speicherverbrauch bei jffs2/squashfs

[tcf4004]

Hi,

kann es sein dass der RAM-Speicherverbrauch bei jffs2/squashfs-Images differiert?
Also beide Images absolut gleich (Neutrino, cvs märz), nur 1x jffs2, 1x squashfs.
Direkt nach Booten und ca. 2 min auf ARD ergibt sich folgendes Bild bei jffs2:

Code: Alles auswählen

              total         used         free       shared      buffers
  Mem:        30888        18512        12376            0            0
 Swap:            0            0            0
Total:        30888        18512        12376

Und bei squashfs siehts so aus:

Code: Alles auswählen

              total         used         free       shared      buffers
  Mem:        30888        22144         8744            0         2608
 Swap:            0            0            0
Total:        30888        22144         8744

Ich hab das Gefühl dass bei squashfs-Images der RAM deutlich schneller verbraucht
wird. Kann das evtl. daran liegen dass Teile des squashfs dekomprimiert im
RAM vorgehalten werden?

Was hat es mit den buffers auf sich, bei jffs2 steht dort immer 0, bei
squashfs ein Wert meist so um die 2000-3000. Muss dieser Wert zu dem free-Wert
addiert werden? Aber eigentlich sollte es ja in der Total-Zeile schon richtig
angezeigt werden...

Nach einigen Stunden habe ich bei squashfs nur noch ca. 3-4mb frei, bei jffs2
hingegen noch 6-7. Womit kann das zu tun haben (wie gesagt Image ist bis aufs
FS genau gleich).

Haben andere User vielleicht ähnliche Erfahrungen gemacht?

Danke & Gruss,
tcf4004

[PauleFoul]

Hmm, schon komisch... Mal sehen ob ein Experte eine Idee zu diesem Thema hat...


Gruß
____Paule

[AudioSlyer]

Bei SquashFS wird der Block, der dekomprimiert werden soll, zunächst ins RAM kopiert, da SquashFS darauf ausgelegt ist, von beliebigen Block-Geräten lesen zu können.
Boote doch beide Images mal ohne den sectionsd und vergleiche...

[tcf4004]

ok, ich hab mir mal nen jffs2/squashfs mit geänderter start_neutrino gebaut, sodass der sectionsd gar nicht erst mit gestartet wird.

Der Trend zu mehr RAM bei jffs2 ist aber auch hier vorhanden, das sind die Werte nach ca. 30 Minuten
(ist zwar nur kurz, aber ohne sectionsd verändert sich der freie RAM-Speicher bereits nach 1-2 min nach Booten so gut wie gar nicht mehr):

Code: Alles auswählen

jffs2:
              total         used         free       shared      buffers
  Mem:        30884        16528        14356            0            0
 Swap:            0            0            0
Total:        30884        16528        14356


squashfs:
              total         used         free       shared      buffers
  Mem:        30884        20448        10436            0         2632
 Swap:            0            0            0
Total:        30884        20448        10436

Also definitiv fast 4MB mehr RAM bei jffs2...
Oder ist das wieder so ne "Cache-Geschichte", dass der RAM bei squashfs
stärker fragmentiert wird und halt ab und zu ein Cleanup nötig ist?
D.h., a la Movieplayer bzw. eine 8-10mb Datei ins RAM kopieren und
anschliessend löschen?

PS: Sind die buffers bei squashfs für die decompression oder wofür sind die?


Danke & Gruss
tcf4004

[tcf4004]

Was ich merkwürdig finde: Hat das sonst keiner oder ist es nur keinem aufgefallen??

Und nochmal die Frage: was hat es mit den buffers auf sich, könnte mir das bitte jemand kurz erklären?

DANKE

[seife]

Ich habe das auch, aber ich weiss nicht, woran es liegt.

Caches sind das, was das Filesystem mit dem VFS-Layer cached. Cache wird vom busybox-free nicht angezeigt, aber in /proc/meminfo sind sie zu finden.
Buffers sind das, was die Blockdevices puffern (zwischen VFS und tatsächlichem Blockdevice)

Zumindest habe ich das so verstanden.

Da jffs2 wohl nicht auf dem blockdevice /dev/mtdblock/X sondern auf /dev/mtd/X seine eigentliche "Arbeit" verrichtet (obwohl /dev/mtdblock/X gemounted wird), kann es sehr gut sein, dass die Lese- und Schreibzugriffe auf jffs2 eben nicht durch den buffercache der blockdevices gehen, und deswegen die buffers 0 sind.
JFFS2 kann man ja auch nur mit MTD-devices mounten, wenn man versucht, das normal mittels loopdevice zu mounten, bekommt man nur

Code: Alles auswählen

Jul  2 19:52:13 stoetzler kernel: [104383.357795] MTD: Attempt to mount non-MTD device "/dev/loop0"

Es gibt auch extra einen "MTD-Simulationstreiber" (mtdram), damit man ein jffs2 loopmounten kann.

Squashfs hingegen ist für den Einsatz auf beliebigen Blockdevices ausgelegt - mit der Konsequenz, dass auch die buffercaches benutzt werden und vermutlich auch zusätzlich Speicher dafür benötigt wird.

Insofern ist es durchaus möglich, dass Squashfs ineffizienter mit dem RAM umgeht, als JFFS2. Ich werde wohl mal ein JFFS2-Image probieren müssen, vielleicht bootet das ja auch noch schneller ;-)

[xfond2]

Was ich merkwürdig finde: Hat das sonst keiner oder ist es nur keinem aufgefallen??

DANKE

also ich habe das auch schon gemerkt, deshalb habe ich für mich das erstellen der images mit jffs2 immer dem squashfs vorgezogen, und ehrlich gesagt für was brauch man den ein image was mit squashfs gepackt ist? ok wenn man alles was geht im image haben möchte ist dies zwingend erforderlich, aber wenn man nur das einbaut was man brauch dann reicht ein jffs2 auf jeden fall vollkommen aus.

[doc]

Jo, nur das jffs2 halt rw ist. Damit kann man auch schnell mal was zerlegen. Man kann auch wieder cramfs nehmen.

[xfond2]

Jo, nur das jffs2 halt rw ist. Damit kann man auch schnell mal was zerlegen. Man kann auch wieder cramfs nehmen.

ja da haste recht, aber wenn man das "prob" kennt dann achtet man halt drauf..
ja das cramfs ist auch net schlecht, dann kann man auch wieder NewTuxFlash nutzen

[AudioSlyer]

Nimm mal den lzma-patch raus und berichte

http://www.squashfs-lzma.org/

[tcf4004]

Vielen Dank für die interessanten Infos und Erklärungen, ich war schon am zweifeln ob es nicht doch an meiner Kompilationsumgebung liegt

Ich werde wohl mal ein JFFS2-Image probieren müssen, vielleicht bootet das ja auch noch schneller ;-)

Geht tatsächlich etwas schneller mit jffs2, etwa 5-10 Sekunden.

Das mit dem lzma-Patch herausnehmen & testen werde ich heute abend mal versuchen,
ich hoffe dass ich das hinbekomme

Danke & Gruss
tcf4004

[rhabarber1848]

Das mit dem lzma-Patch herausnehmen & testen werde ich heute abend mal versuchen,
ich hoffe dass ich das hinbekomme

Dabei könntest Du gleich meinen Patch testen:
http://forum.tuxbox-cvs.sourceforge.net ... 07#p358407

[tcf4004]

So, hier nun mit rhabarber1848's Patches folgendes Ergebnis ohne lzma (mit sectionsd):

Code: Alles auswählen

Direkt nach Start:
              total         used         free       shared      buffers
  Mem:        30888        21332         9556            0         3380
 Swap:            0            0            0
Total:        30888        21332         9556


Nach 15min Betrieb/Zapping:
              total         used         free       shared      buffers
  Mem:        30888        25856         5032            0         3480
 Swap:            0            0            0
Total:        30888        25856         5032

Also immer noch dasselbe, d.h. eigentlich sollte dann lzma nichts damit zu tun haben...?
Auch werden ohne lzma offenbar noch mehr buffers verwendet als mit.

Allerdings ist mit den Patches lzma (zumindest im 2.4er Kernel) offenbar _immer_ ausgeschaltet, auch mit
--enable-lzma configure option, aber um die beiden Threads nicht zu vermischen habe ich den Rest in dem
Thread von rhabarber1848 gepostet.

[AudioSlyer]

Das kreist den "Fehler" doch schon ein.
Bei openWRT hatten die auch mal was bezüglich Speicherverbrauch...
Bei SquashFS 3.3 gibt es SQUASHFS_FRAGMENT_CACHE_SIZE...