emus shrinken?

[wiwe]

Hallo,

 

Frage an die Baumeister des KW-Images:

 

Ist es zweckmäßig die emus (z.B. camd3, mgcamd, ccam) zu shrinken, um mehr Platz auf der box zu gewinnen? Habe das jetzt mal mit MGcamd probiert und es klappt. Speicherbedarf um mindestens 30% gesunken.

 

Wenn das durch das Image toleriert wird, wäre es doch gut, wenn eine solche Routine direkt in den Menüpunkt Camdupdate von Keywelt-Service eingebaut würde!

 

Ich bin neuer User von KW-Image Sept. Habe in der Boardsuche nach dem Thema gesucht, aber nichts gefunden.

 

Gruß

 

wiwe

[Gast kingmattes]

Schau mal hier

 

und hier kannst Du es ausführlich nachlesen. Da haben es Worschter und Snowhead mal getestet.

[wiwe]

Schau mal hier

Hallo kingmattes,

 

Danke für den Hinweis. Wenn das stimmt, dann müsste aber die Anzeige über den noch verfügbaren Platz auf der Box falsch sein! Der zeigt nämlich nach dem shrinken wesentlich mehr Platz an. Oder habe ich was an den Augen?

 

Kann auch nicht bestätigen, dass eine geshrinkte Camd langsamer anspricht.

 

Shrinken ist ja an sich kein Problem. Man kann das gut "händisch" über putty oder telnet auf der box ausführen. Für das Sportster-Image hat atzi dort ein komfortables Plugin für das shrinken geschrieben. Ich dachte nur daran, dass sowas für die KW-User auch was sein könnte.

 

Gruß

 

wiwe

[merkwuerden]

@wiwe

 

Ich hab das grade mal ausprobiert: Deine 30% Platzersparnis kannste vergessen.

 

mgcamd v1.16 nimmt ungeshrinkt 164 kB, geshrinkt 156 kB im /var in Anspruch. Sind grade mal knapp 5% Ersparnis, das ist der ganze Aufwand nicht wert.

 

Wenn Du den wirklichen Speicherbedarf im Image wissen willst, geht das im KW-Image so:

- /var Bereich des Images defragmentieren (über das eingebaute Defrag) und neu flashen

- über telnet (df) Speicherbelegung von /var ermitteln

- zu prüfende Datei einspielen

- /var Bereich wieder defragmentieren und flashen

- mit telnet (df) neue Speicherbelegung ermitteln

Das Prozedere darfst Du dann bei jeder Datei so machen, um verläßliche Werte zu erhalten. Defrag auch erfoderlich, wenn eine Datei wieder gelöscht wird.

 

Das Defragmentieren deswegen, weil es sonst selbst beim Einspielen und sofortigem Löschen derselben Dateie zu Unterschieden in der Anzeige der Speicherbelegung kommen kann. Dürfte am JFFS2-Journal liegen.

Ich hatte das mal mit einer Testinstallation eines yweb-Updates (manuell eingespielt), das hat bei jedem Mal Einspielen und Löschen einen anderen Speicherverbrauch gehabt, mal nur 400 kB, dann plötzlich über 500 kB, dann irgendwo zwischendrin...

[wiwe]

Hallo merkwuerden,

 

vielen Dank für Deine Ausführungen. Hab das jetzt mal selbst auf Deine Weise probiert und komme zwar nicht auf den niedrigen Wert von Dir, aber es sind jetzt auch keine 30% mehr.

 

Inzwischen habe ich auch mal den Thread von damals durchstudiert, zu dem kingmattes die Links hierhergestellt hat. Da hat ja damals +Worschter+ auch sehr gründliche Versuche gemacht. Die Geheimnisse von JFFS2 sind mir in diesem Unfang bisher nicht bekannt gewesen. Nachdem ich nun auch KEYWELT_V2_SEPTEMBER_BETA3_neu aufgespielt habe und die Spiele, die nicht jeder benötigt, runter sind, sieht das mit dem Platz schon etwas anders aus.

 

Gruß

 

wiwe