Kompression ausführbarer Dateien vs. SquashFS

[hermann72pb]

Ich hab so eine wilde Idee, weil einer hier sich darüber geäußert hat. Wäre es möglich im RAM auch LZMA-"Partitionen" (Bereiche) anzulegen und zu definieren? Macht es überhaupt Sinn? Was spricht dagegen/dafür? Wie schwer lässt sich sowas realisieren?
Ich denke z.B. an OpenVPN unter 7050. Momentan wird es bei mir vom Server runtergeladen und ins RAM gelegt. Und natürlich wie oben gemerkt im ausgepackten Zustand.

MfG

 

[kriegaex]

Wenn das Sinn machen würde, gäbe es das schon. Das LZMA-Packen ist ungleich anspruchsvoller bzgl. Rechenzeit und Speicherbedarf, und das müßte ja dynamisch auf der Box passieren. Bad idea.

 

[bodega]

Ist Asterisk nicht als SquashFS Image verpackt??

 

[kriegaex]

Schon möglich, frag doch mal im Schwesterforum. Oder war das eine rhetorische Frage?

 

[bodega]

So halb/halb. Ich habe nur mal gesehen, dass es ein Asterisk.sqf gibt.

 

[kriegaex]

Das ist ein SquashFS-Image, aber ohne LZMA (also GZIP), habe es eben mal schnell angeschaut. Wie das benutzt wird, habe ich nicht geschaut, evtl. als Loop-Mount aus der RAM-Disk heraus. Kann man schon so machen, wenn man das möchte. Wir würden es aber eher ins DS-Mod-Image packen aus den genannten Gründen. Und wie gesagt, auf einem externen Speicher bräuchte man es nicht unbedingt zu packen.

 

[olistudent]

Das gibts im anderen Verzeichnis auch mit lzma.

MfG Oliver

 

[RalfFriedl]

Der RAM-Bedard ist nicht sonderlich zu beachten, denn:
"no memory overhead for your compressed executables because of in-place decompression."
Direkt von der Webseite.

Die Frage ist, was passiert, wenn ein Programm mehrfach aufgerufen wird. Wird dann das einmal dekomprimierte Abbild gemeinsam genutzt oder nicht?

Wenn das nicht der Fall ist, würde eine upx komprimierte Busybox für jeden einzelnen Prozeß, der Busybox ausführt, eine eigene Kopie im Speicher anlegen. Das Ergebnis wäre ein sehr hoher Speicherplatzverbrauch.

Ich habe mal in das upx hinein geschaut, aber noch nicht herausgefunden, wie es sich verhält.

 

[gfuer]

Und eine weitere Frage ist, ob gleich das gesamte Binary dekomprimiert wird? Beim SquashFS werden ja IMO nur die Pages dekomprimiert, auf die der Prozeß tatsächlich zugreift, und die dann vom Page-Fault-Handler in den Speicher geladen werden. Und das "Working Set" eines Prozesses ist ja u.U. nur ein Bruchteil des kompletten Codes.

 

[RalfFriedl]

Man kann davon ausgehen, daß das gesamte Binary dekomprimiert wird.

Ansonsten müßte sich UPX ja noch in die Speicherverwaltung mit hineinhängen, das würde den upx Runtime komplexer und größer machen, sofern man das überhaupt ohne Eingriffe am System transparent für das laufende Programm erreichen kann.

Beim SquashFS werden nicht Pages dekomprimiert, sondern Blöcke, die in der Default-Einstellung 64k groß sind. Beim SquashFS 3 werden auch Blöcke bis 1MB unterstützt.

Aber es ist richtig, daß nicht unbedingt das gesamte Binary auf einmal im Speicher sein muß.

Vom Ansatz ist es sicher effizienter, das Dateisystem zu komprimieren und einen Dekomprimierer im Kernel zu haben, als jedes Binary einzelne zu komprimieren.

Die Frage ist nur, ob die von UPX verwendete Komprimierung besser ist und wenn ja, ob diese auch ins SquashFS integriert werden kann.

 

[spblinux]

Das ist ein SquashFS-Image, [alte Versionen] ohne LZMA (also GZIP) [und aktuelle mit LZMA], ... Wie das benutzt wird...

Die Daten vom squashfs werden direkt gemountet; die ramdisk ist ja dafür da, dass ein Stück ram als block device erscheint. (lzma gibt es, seit die firmware von avm das unterstützt).

Speicherbedarf sind also einmal die squashfs-Daten selber und andererseits die entpackten Blöcke, die tatsächlich in Verwendung sind. - Nützlich und praktisch, wenn man etwas RAM übrig hat.

... beim dsmod war mal die Rede von zur Laufzeit nachladbaren Addons. Die gibt es, glaube ich, immer noch nicht. (Falls doch, bin ich dankbar für einen Hinweis).

spblinux

 

[gfuer]

Werden die "squashfs-Daten selber" beim Zugriff auf das FS direkt aus dem Flash-Speicher gelesen und dekomprimiert, oder existiert auch eine Kopie der (komprimierten) squashfs-Daten in einer RAM-Disk?

 

[RalfFriedl]

Das gesamte SquashFS aus dem Flash wird nicht komplett ins RAM kopiert.

Der Block, der dekomprimiert werden soll, wird aber zunächst ins RAM kopiert, da SquashFS darauf ausgelegt ist, von beliebigen Block-Geräten lesen zu können.

 

[kriegaex]

@spblinux: Meine Aussage war nur auf die Datei gemünzt, deren Link hier gepostet wurde. Ich habe nicht weiter geforscht und auch kein Interesse daran, weil ich Asterisk nicht brauche. Die nachladbaren Add-Ons gibt es nur selbstgemacht per Downloader-CGI. Die iPKG-Pakete gibt es immer noch nicht, und es arbeitet auch keiner daran, weil Danisahne das machen wollte. Wie weit er ist, kannst Du auf http://ds-mod.sourceforge.net nachprüfen, Oliver und ich arbeiten daran nicht, und Daniel scheint durch seinen Job auch sehr ausgelastet zu sein. Um ehrlich zu sein, arbeiten wir momentan so, daß wir nicht damit rechnen, der Sourceforge-Mod würde jemals fertig werden. Falls doch, ist es eine positive Überraschung und wir freuen uns auch. Wer weiß, vielleicht machen wir auch mal an iPKG weiter, wenn Daniel sagt, er hat nicht mehr vor weiterzumachen, aber momentan nicht.

Was Pakete betrifft: Ich denke eher, die Zukunft für viele Nutzer sind unsere neuen Funktionen für 15.3, nämlich USB-Root (booten von Platte oder Stift), NFS-Root (dito. über Netzwerk) bzw. im Einzelfall auch mini_fo + JFFS, der richtige Schritt in Richtung Speicherplatz-Erweiterung, da zumindest durch die ersteren beiden kein RAM als "Festplatte" mißbraucht wird.

 

[spblinux]

... USB-Root, NFS-Root

Klingt gut!

spblinux

 

[bodega]

Wie wird eigentlich eine SquashFS Datei auf der FB gemountet? Leider habe ich das nicht hinbekommen. Irgendwie muss ein Loop-Device mit mknod erzeugt werden und dann wird gemountet ...?!?

Wäre schön, wenn mir das einer erklären könnte...

 

[RalfFriedl]

Die Dateien /dev/loop[0-1] sollten schon vorhanden sein, weitere können bei Bedarf angelegt werden.

Die einfachste Art, diese zum Mounten zu verwenden ist die loop Option bei mount:

mount -o loop /dev/xxx /dir

Damit wird automatisch ein loop Device zum Mounten verwendet und beim unmount wieder freigegeben.

 

[bodega]

Beim freetz habe ich zwei Loop-Devices gefunden. Ohne freetz würde man ja folgendes machen:

mknod /var/loop0 b 7 0

Nur wenn ich dann mounten möchte, kommt folgendes:

mkdir /var/sqfdir
cat test.sqf > /var/loop0
-sh: cannot create /var/loop0: No such device or address
mount -o loop /var/loop0 /var/sqfdir
mount: Mounting /var/loop0 on /var/sqfdir failed: No such device or address

Hast du eine Idee? Beim freetz ist es genauso...

EDIT:
ok:

# cat /proc/devices
Character devices:
255 avm_net_trace
  1 mem
  2 pty
  3 ttyp
  4 ttyS
  5 /dev/tty
  5 /dev/console
  5 /dev/ptmx
 10 misc
 13 input
 68 capi_oslib
 90 mtd
128 ptm
136 pts
180 usb
226 kdsld_traffic
228 userman
229 kdsld_user
230 tiatm
240 tffs
241 avm_event
242 watchdog
243 kdsld
244 kdsldptrace
245 ubik2
246 debug
251 avm_led
252 avm_power

Block devices:
  8 sd
 31 mtdblock
 65 sd
 66 sd
 67 sd
 68 sd
 69 sd
 70 sd
 71 sd
128 sd
129 sd
130 sd
131 sd
132 sd
133 sd
134 sd
135 sd

mknod /var/loop0 b 8 0
# cat test.sqf > /var/loop0
# mount -o loop /var/loop0 /var/sqfdir
mount: Mounting /var/loop0 on /var/sqfdir failed: Device or resource busy

 

[dsteinkopf]

Evtl. fehlt Dir das Kernel-Modul loop.ko:

insmod .../loop.ko

bzw.

modprobe loop

Dazu muss es im make menuconfig ausgewählt sein.


Dirk

 

[bodega]

Mhh.. das kann gut sein. Ich werde das heute Abend nochmal probieren und hier posten.