Worschter Geschrieben 4. Februar 2006 Melden Share Geschrieben 4. Februar 2006 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 Link zu diesem Kommentar Auf anderen Seiten teilen More sharing options...
Quintus 2 Geschrieben 4. Februar 2006 Melden Share Geschrieben 4. Februar 2006 (bearbeitet) 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 Link zu diesem Kommentar Auf anderen Seiten teilen More sharing options...
Worschter Geschrieben 4. Februar 2006 Autor Melden Share Geschrieben 4. Februar 2006 ich glaub ich stell mich jetzt etwas dumm an. Wie ich Dich verstehe hast Du im Keywelt Image jetzt was geshrinktes am Laufen, richtig? Link zu diesem Kommentar Auf anderen Seiten teilen More sharing options...
picchu Geschrieben 4. Februar 2006 Melden Share Geschrieben 4. Februar 2006 Was ist denn geschrinktes? Link zu diesem Kommentar Auf anderen Seiten teilen More sharing options...
Worschter Geschrieben 4. Februar 2006 Autor Melden Share Geschrieben 4. Februar 2006 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. Link zu diesem Kommentar Auf anderen Seiten teilen More sharing options...
Worschter Geschrieben 4. Februar 2006 Autor Melden Share Geschrieben 4. Februar 2006 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 Link zu diesem Kommentar Auf anderen Seiten teilen More sharing options...
Admin SnowHead Geschrieben 4. Februar 2006 Admin Melden Share Geschrieben 4. Februar 2006 @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 Link zu diesem Kommentar Auf anderen Seiten teilen More sharing options...
Worschter Geschrieben 4. Februar 2006 Autor Melden Share Geschrieben 4. Februar 2006 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 Link zu diesem Kommentar Auf anderen Seiten teilen More sharing options...
Admin SnowHead Geschrieben 4. Februar 2006 Admin Melden Share Geschrieben 4. Februar 2006 @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. Link zu diesem Kommentar Auf anderen Seiten teilen More sharing options...
Worschter Geschrieben 4. Februar 2006 Autor Melden Share Geschrieben 4. Februar 2006 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 Link zu diesem Kommentar Auf anderen Seiten teilen More sharing options...
merkwuerden Geschrieben 4. Februar 2006 Melden Share Geschrieben 4. Februar 2006 Ich würde die Shrinkerei bleiben lassen, wirkliche Vorteile bringt's wohl nicht. Link zu diesem Kommentar Auf anderen Seiten teilen More sharing options...
Quintus 2 Geschrieben 4. Februar 2006 Melden Share Geschrieben 4. Februar 2006 (bearbeitet) 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 Link zu diesem Kommentar Auf anderen Seiten teilen More sharing options...
Quintus 2 Geschrieben 4. Februar 2006 Melden Share Geschrieben 4. Februar 2006 (bearbeitet) 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 Link zu diesem Kommentar Auf anderen Seiten teilen More sharing options...
Worschter Geschrieben 4. Februar 2006 Autor Melden Share Geschrieben 4. Februar 2006 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 Link zu diesem Kommentar Auf anderen Seiten teilen More sharing options...
Quintus 2 Geschrieben 4. Februar 2006 Melden Share Geschrieben 4. Februar 2006 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 Link zu diesem Kommentar Auf anderen Seiten teilen More sharing options...
Worschter Geschrieben 4. Februar 2006 Autor Melden Share Geschrieben 4. Februar 2006 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 Link zu diesem Kommentar Auf anderen Seiten teilen More sharing options...
Admin SnowHead Geschrieben 4. Februar 2006 Admin Melden Share Geschrieben 4. Februar 2006 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. Link zu diesem Kommentar Auf anderen Seiten teilen More sharing options...
Bobbelsche Geschrieben 4. Februar 2006 Melden Share Geschrieben 4. Februar 2006 Ö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ß! Link zu diesem Kommentar Auf anderen Seiten teilen More sharing options...
merkwuerden Geschrieben 5. Februar 2006 Melden Share Geschrieben 5. Februar 2006 Eben. Ich höre jetzt schon das Gefluche von den Leuten, wenn die eine geshrinkte Datei austauschen wollen und hinterher alles hin ist. Link zu diesem Kommentar Auf anderen Seiten teilen More sharing options...
bsdice Geschrieben 5. Februar 2006 Melden Share Geschrieben 5. Februar 2006 (bearbeitet) . bearbeitet 20. Februar 2008 von bsdice Link zu diesem Kommentar Auf anderen Seiten teilen More sharing options...
Quintus 2 Geschrieben 5. Februar 2006 Melden Share Geschrieben 5. Februar 2006 @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 Link zu diesem Kommentar Auf anderen Seiten teilen More sharing options...
Gast g5401 Geschrieben 8. Februar 2006 Melden Share Geschrieben 8. Februar 2006 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 Link zu diesem Kommentar Auf anderen Seiten teilen More sharing options...
Worschter Geschrieben 8. Februar 2006 Autor Melden Share Geschrieben 8. Februar 2006 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 Link zu diesem Kommentar Auf anderen Seiten teilen More sharing options...
Gast g5401 Geschrieben 8. Februar 2006 Melden Share Geschrieben 8. Februar 2006 Stimmt ich hab das nur nicht genannt, damit nicht der Imageplatzer mit euremImage 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 Link zu diesem Kommentar Auf anderen Seiten teilen More sharing options...
Worschter Geschrieben 8. Februar 2006 Autor Melden Share Geschrieben 8. Februar 2006 @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 Link zu diesem Kommentar Auf anderen Seiten teilen More sharing options...
Empfohlene Beiträge