shrinken im Image ja/nein ?

[Worschter]

Hi,

 

nicht daß jetzt der Gedanke aufkommt, ich wollte shrink ins Keywelt Image aufnehmen,

dem ist nicht so, weil ich nicht wirklich Bedarf dafür sehe.

 

Mich interessiert nur mal in wie weit da wirklich was gewonnen wird.

 

zum Test hab ich mal im Keywelt Image die

375416 byte (=367kB) grosse camd3.837 genutzt und hab sie mal kopiert.

 

mit df kann man das Ergebnis ansehen.

 

Filesystem          1k-blocks      Used Available Use% Mounted on

/dev/root                5184      5184        0 100% /

/dev/mtdblock/2          2688      1812      876  67% /var

/var/bin # cp camd37xx test

/var/bin # df

Filesystem          1k-blocks      Used Available Use% Mounted on

/dev/root                5184      5184        0 100% /

/dev/mtdblock/2          2688      2040      648  76% /var

 

man sieht also, das JFFS2 Filesystem bringt schonmal ne Compression mit sich, da die camd3

im Image selbst nur 228kB belegt. Die camd3 hat im Image also 67% der eigentlichen Grösse.

 

Wäre klasse, wenn sich mal jemand mit nem Shrink Image die Mühe machen würde um nen Vergleich zu haben.

 

Vielen Dank

[Quintus 2]

Also eindeutig JA

das bringt auf jedenfall was,hab die busy drin kopiert und die camd 3(plus böse vogel)geshrinkt,und in /bin verschoben und die funtzen wunderbahr(warum 228kb bei mir sind 196kb)

 

"/var # cd bin

/var/bin # cp camd37xx test

/var/bin # df

Filesystem 1k-blocks Used Available Use% Mounted on

/dev/root 5184 5184 0 100% /

/dev/mtdblock/2 2688 2268 420 84% /var"

 

 

 

 

ich hab vohrer nicht gesehen wie viel noch frei wahr,eins weiss auf jeden fall,voher waren laut "system info"activ 7,8 mb/jetz sind 7,3mb.

 

 

Quintus2

bearbeitet 4. Februar 2006 von Quintus 2

[Worschter]

ich glaub ich stell mich jetzt etwas dumm an.

 

Wie ich Dich verstehe hast Du im Keywelt Image jetzt was geshrinktes am Laufen, richtig?

[picchu]

Was ist denn geschrinktes?

[Worschter]

beim Shrinken werden ne selbstentpackende, lauffaähige, komprimierte Dateien erzeugt.

Das spart Platz im Image.

 

Mein Ziel ist es mal nen Vergleich zu haben wie sehr das Platz spart.

[Worschter]

also nun mal mein doch recht ernüchterndes Ergebnis:

 

hab ein bekanntes Image geflasht das mit shrink arbeitet und da die aktuelle camd3 geshrinkt und in den

/var Bereich verschoden.

 

die camd3 hatte wie oben genannt die 376kB und nach dem shrinken :

-rwxrwxrwx    1 root    root      201522 Feb  4 18:36 camd3

-rwxrwxrwx    1 root    root      375416 Feb  4 18:35 camd3~

gute 200kB in /tmp

 

als ich die dann nach /var verschoben hab, folgendes:

Filesystem          1k-blocks      Used Available Use% Mounted on

/dev/root                7936      6992      944  88% /

/tmp # cp camd3 /var/emu/camd3

/tmp # df

Filesystem          1k-blocks      Used Available Use% Mounted on

/dev/root                7936      7316      620  92% /

 

das wären 324 kB im Flash??? Dacht mir das kann nicht sein, da muss ich mal rerbooten.

Ergebnis erstmal :"kein System"

 

Jetzt werd ich mal schauen daß ich das wieder auf die Reihe krieg und nochmal wiederhole.

Ohne Windows wird das ne Tortour

[SnowHead]

@Worschter

 

Ich kann jetzt nicht ganz nachvollziehen, was genau Du veranstaltest.

Blauäugig wie ich bin, habe ich die camd37xx mal zur camd37x ge-

shrinkt und auch nach /var/bin/ geschoben. Das Ergebnis sieht so aus:

vor Einspielen der geshrinkten Camd3 nach /var/bin/:

/dev/mtdblock/2		   2688	  1756	   932  65% /var

und danach

/dev/mtdblock/2		   2688	  1952	   736  73% /var

und die Größe im Flash:

-rw-r--r--	1 root	 root	   200043 Feb  4 18:56 /var/bin/camd37x
-rwxr-xr-x	1 root	 root	   375416 Jan 27 17:37 /var/bin/camd37xx

[Worschter]

naja,

 

ich hab mir gedacht, JFFS2 komprimiert ja von Haus aus schon.

Das heisst, eine 376kB grosse camd3 belegt im Image keine effektiven 376kb sondern

wie oben angezeigt im Keywelt Image nur 228kB

Das sieht man aber nicht mit

ls -la

weil da die Originalgrösse angezeigt wird. Alleine df kann dies offenlegen in dem man die belegten Blöcke im

/var Bereich ansieht.

 

Nun dacht ich mir, meistens holt man aus komprimierten Dateien nicht unbedingt noch ne wesentlich höhere

Packrate raus. Ich wollte nun einfach feststellen, wieviel Speicher man effektiv im Image spart von den 8MB

[SnowHead]

@Worschter

 

Dann hier mal der /var/-Bereich ohne Camd3:

/dev/mtdblock/2           2688      1756       932  65% /var

nur mit geshrinkter Camd3:

/dev/mtdblock/2           2688      1952       736  73% /var

und hier mit ungeshrinkter:

/dev/mtdblock/2           2688      1984       704  74% /var

 

Macht summa summarum eine Einsparung von 32 Blöcken.

[Worschter]

jo genau das hab ich gesucht

 

32kB Speichergewinn bei 375kb, das sind etwa 8%.

 

wenn ich mir überlege wie wenig man ansich shrinken kann, sind ja ansich nur die Binarys oder?

Dann rechnen wir mal hoch:

 

das Keywelt Image hat 2688 K frei. bei einem Anteil von 70% shrinkbaren Sachen (grob geschätzt)

sind das dann noch gute 5%

 

2688*1,05= 2822

 

möglicher Gewinn 134kb. Wenn ich dem gegenüberstelle, daß dann aber alle Scripte nicht mehr

editierbar vorliegen würden + den Aufwand die Sachen shrinken zu müssen?

 

Also im Squashfs Image stell ich mal den Nutzen von shrink sehr in Frage.

Zumal es im wesentlich höher, bzip2 komprimierten Squashfs Bereich wohl durch die zusätzlichen

Dateianhänge von shrink eher grösser würde

 

Aber vielleicht kann mal jemand der sich damit mehr befasst hat etwas zu sagen

[merkwuerden]

Ich würde die Shrinkerei bleiben lassen, wirkliche Vorteile bringt's wohl nicht.

[Quintus 2]

ich glaub ich stell mich jetzt etwas dumm an.

 

Wie ich Dich verstehe hast Du im Keywelt Image jetzt was geshrinktes am Laufen, richtig?

genau das,und das leuft und leuft und leuft..............................

 

 

 

 

 

 

wahr ich essen mit meine frau und jetz zurück und das ding leuft immer noch wie eine uhrwerk Na ups bin ich der ERSTE der eine geshrinkte datei (2) benütz hat?

 

 

 

 

 

Quintus2

 

 

merkwuerden hab bis jetz ne andere geshrinkte img auf dieses box gehabt die bei mir nie geplatz ist(die habe ich noch auf 3 andere boxen am laufen)

bearbeitet 4. Februar 2006 von Quintus 2

[Quintus 2]

also nun mal mein doch recht ernüchterndes Ergebnis:

 

hab ein bekanntes Image geflasht das mit shrink arbeitet und da die aktuelle camd3 geshrinkt und in den

/var Bereich verschoden.

 

die camd3 hatte wie oben genannt die 376kB und nach dem shrinken :

-rwxrwxrwx    1 root     root       201522 Feb  4 18:36 camd3

-rwxrwxrwx    1 root     root       375416 Feb  4 18:35 camd3~

gute 200kB in /tmp

 

als ich die dann nach /var verschoben hab, folgendes:

Filesystem           1k-blocks      Used Available Use% Mounted on

/dev/root                 7936      6992       944  88% /

/tmp # cp camd3 /var/emu/camd3

/tmp # df

Filesystem           1k-blocks      Used Available Use% Mounted on

/dev/root                 7936      7316       620  92% /

 

das wären 324 kB im Flash??? Dacht mir das kann nicht sein, da muss ich mal rerbooten.

Ergebnis erstmal :"kein System"

 

Jetzt werd ich mal schauen daß ich das wieder auf die Reihe krieg und nochmal wiederhole.

Ohne Windows wird das ne Tortour

also wie kommst du auf 92%?

 

ich mit der ganze schrott was reingeschmissen habe komme mit viel weniger

 

 

"have fun with KEYWELT on your Nokia D-BOX2 - Kernel 2.4.31-dbox2 (23:04:23)...

dbox login: root

 

 

BusyBox v1.01 (2005.12.28-01:21+0000) Built-in shell (ash)

Enter 'help' for a list of built-in commands.

 

/var # cd bin

/var/bin # cp **** /var/bin/****

cp: `****' and `/var/bin/**** are the same file

/var/bin # df

Filesystem 1k-blocks Used Available Use% Mounted on

/dev/root 5184 5184 0 100% /

/dev/mtdblock/2 2688 2268 420 84% /var

 

 

 

quintus2

 

 

 

vielleicht mit hilfe von SnowHead(alter Fuchs)könnte man auch diese werte erreichen!

"/var # df

Filesystem 1k-blocks Used Available Use% Mounted on

/dev/root 4736 4736 0 100% /

/dev/mtdblock/2 3200 1904 1296 60% /var

/var #(aus ne andere geshrinkte img)

bearbeitet 4. Februar 2006 von Quintus 2

[Worschter]

also wie kommst du auf 92%?

 

das war wie schon gesagt ein andres Image nicht das Keywelt Image

 

 

vielleicht mit hilfe von SnowHead(alter Fuchs)könnte man auch diese werte erreichen!

"/var # df

Filesystem 1k-blocks Used Available Use% Mounted on

/dev/root 4736 4736 0 100% /

/dev/mtdblock/2 3200 1904 1296 60% /var

/var #(aus ne andere geshrinkte img)

 

och nö, da seh ich nicht den Bedarf muss ich ehrlich sagen.

 

Aber diese Grundsatzdiskussion hatten wir schon öfters. Ich denke mal wenn man sich ausgiebig mit dem

der Philosophie hinterm keywelt Imag befasst, dann wird man irgendwann feststellen, so wie´s ist ist es ganz gut

[Quintus 2]

also wie kommst du auf 92%?

 

das war wie schon gesagt ein andres Image nicht das Keywelt Image

 

 

vielleicht mit hilfe von SnowHead(alter Fuchs)könnte man auch diese werte erreichen!

"/var # df

Filesystem 1k-blocks Used Available Use% Mounted on

/dev/root 4736 4736 0 100% /

/dev/mtdblock/2 3200 1904 1296 60% /var

/var #(aus ne andere geshrinkte img)

 

och nö, da seh ich nicht den Bedarf muss ich ehrlich sagen.

 

Aber diese Grundsatzdiskussion hatten wir schon öfters. Ich denke mal wenn man sich ausgiebig mit dem

der Philosophie hinterm keywelt Imag befasst, dann wird man irgendwann feststellen, so wie´s ist ist es ganz gut

WIE DU GEHST FREMD?

 

 

 

HAB NOCH DIE AES UPDATER DRIN! FA BE LAFT

 

QUINTUS 2

[Worschter]

WIE DU GEHST FREMD?

 

Naja, musste ja ein Vergleichs Image nehmen wo ich mir sicher bin, daß shrink auch geht.

 

HAB NOCH DIE AES UPDATER DRIN! FA BE LAFT

 

meinst Du

Keywelt Menü -> Image /camd-aktualisierung -> AES-Keys über Internet updaten

[SnowHead]

Nöö, also so'n "shrink" stört nur beim Basteln und erhöht die Startzeiten

der Binaries. Da sollten wir versuchen, so lange wie möglich ohne aus-

zukommen.

[Bobbelsche]

Öh also ich denke shrinken ist es nicht Wert die Startzeit zu verlängern. Ich habe am Image schon alles drauf gepackt was ich wohl eh nie nutzen werde und dennoch erst 53% in /var. Ich kann mir kaum vorstellen, was man noch alles reinpacken könnte Und für die Hardcore Leute gibt´s noch CIFS

Ich denke shrinken ist nicht nötig

Gruß!

[merkwuerden]

Eben. Ich höre jetzt schon das Gefluche von den Leuten, wenn die eine geshrinkte Datei austauschen wollen und hinterher alles hin ist.

[bsdice]

.

bearbeitet 20. Februar 2008 von bsdice

[Quintus 2]

@Worschter

meinst Du

Keywelt Menü -> Image /camd-aktualisierung -> AES-Keys über Internet updaten

 

ich ESEL der ist schon drin?

 

(have die 0.15 version rein geschoben )

 

ich glaube jetz muss ich mich doch mit der blaue taste außenandern setzen,befor weiter sc***ße baue.

 

 

 

quintus2

[Gast g5401]

Eben. Ich höre jetzt schon das Gefluche von den Leuten, wenn die eine geshrinkte Datei austauschen wollen und hinterher alles hin ist.

Warum? Man muß die vorhandene Datei nicht zwingend gegen eine geshrinkte austauschen. Die kann auch ungeshrinkt sein. Das ist egal.

 

das Keywelt Image hat 2688 K frei. bei einem Anteil von 70% shrinkbaren Sachen (grob geschätzt)

sind das dann noch gute 5%

 

2688*1,05= 2822

 

möglicher Gewinn 134kb. Wenn ich dem gegenüberstelle, daß dann aber alle Scripte nicht mehr

editierbar vorliegen würden + den Aufwand die Sachen shrinken zu müssen?

 

Also im Squashfs Image stell ich mal den Nutzen von shrink sehr in Frage.

HI! Da gebe ich dir vollkommen Recht. Beim squashfs noch shrinken ist meiner Meinung nach mehr als fragwürdig.

 

Beim jffs2 sehe ich das anders ( wahrscheinlich haste mit dem NG getestet ).

 

Wenn man um jedes freie KB kämpfen muß, dann ist das Shrinken schon eine Alternative. Im bin Verzeichnis zB sind files drinne wo sich shrinken schon lohnt (ZB neutrino oder nhttpd ). Grob geschätzt haben wir wohl einen Platzgewinn von ca. 300-350 KB. Das Ng-Image ist schon von Anfang an geshrinkt und über die Stabilität des Images wurde nicht mehr geklagt als bei ungeshrinkten Images. Im Gegenteil, das NG-Image wird als sehr stabil geshen. Skripte shrinken kann man allerdings vergessen. Das führt zu Fehlern.

 

Wir haben auch beim Bereitstellen der Camd-Updates keine Arbeit mit dem Shrinken, weil das ganze während dem Update automatisch passiert

 

Fazit. Die ganze Geschichte ist wie immer eine Ansichtssache

 

Gruß g5401

[Worschter]

Beim jffs2 sehe ich das anders ( wahrscheinlich haste mit dem NG getestet ).

 

Stimmt ich hab das nur nicht genannt, damit nicht der Imageplatzer mit eurem

Image in Verbindung gebracht wird

 

Im JFFS2 Image seh ich shrinken durchaus als sinnvoll an, weil wie Du schon geschrieben

hast, da wesentlich mehr Dateien nur effektiv komprimiert werden

[Gast g5401]

Stimmt ich hab das nur nicht genannt, damit nicht der Imageplatzer mit eurem

Image in Verbindung gebracht wird

da hab ich keine Probleme mit. Ist das normalste von der Welt.

 

Was ich festgestellet habe, ist, daß das Image, wenn es mal aufgebläht war kaum noch platzen tut.Ich habe einen Füllstand von 95% und tue ständig updaten. da passiert garnix. Is schon seltsam.

 

Gruß g5401

[Worschter]

@g5401

 

ansich solls ja ab Kernel 2.4.31 garnicht mehr platzen, zumindest nicht unwiderruflich.

 

Aber das ist wohl auch nur Theorie. Tatsächlich schafft man es doch das System

klein zu kriegen. Man muss anscheinend nur einen ungünstigen Zeitpunkt zum beschreiben erwischen.

Beim SquashFS ist das zm Beispiel kurz nach dem Mounten des VAR Bereichs.

einmal da ne Datei erstellen und das Image nie mehr nutzen