Neuer SpeedFix ohne auf SDKarte zu verschieben

Update 11.08.2010 Neue Skript Version für die Dev Firmwares Online!

Wichtig: Das Galaxy S muss gerootet sein! Keine Haftung für eventuelle Schäden an deinem Handy. Wenn du dir nicht sicher bist, warte bitte auf ein Update von Samsung, dass hoffentlich dann auch den Lag Bug behebt.

Update 11.08.2010 Es empfiehlt sich doch den autokiller (gibt es kostenlos im Market) mit den Einstellungen 50/60/70 zu installieren. Da der zweite SGS Bug mit dem Memory Management (70MB Grenze) sonst das System nach einer gewissen Zeit doch wieder verlangsamen kann. Danach sollte dauerhaft mit diesem hier beschriebenen Fix eine gute Arbeitsgeschwindigkeit vorhanden sein.

Die einfache Methode:

1. Download der neuen Skript Version SpeedUp (incl. der richtigen busybox) unter http://www.linux-linux.de/speedup.rar.Mit einer Dev Firmware (JM5/JM2) kannst du auch diese Version anwenden http://www.linux-linux.de/SpeedfixM.rar (verschiebt auch /dbdata/databases-was abermals mehr Geschwindigkeit bringt)
2. Auf dem Rechner entpacken
3. Auf dem Galaxy S folgendes einstellen:
Einstellungen->Anwendungen->Entwicklung->Häckchen bei USB-Debugging setzen und JA klicken
4. Telefon per USB an den Computer anschließen
5. Nun in den Ordner (wo du vorher die RAR Datei entpackt hast) gehen und doppelt auf die Datei lagfixme klicken.
6. Wenn auf deinem Bildschirm in großen Buchstaben das Wort "Fertig!" erscheint, hast du den LagFix angewendet.
7. Viel Spaß mit dem schnellen Galaxy S

Die Bastler Methode:

1. Folgende Datei runter laden:
http://linux-linux.de/tools.rar
2. Alles ins Android SDK (download unter http://developer.android.com/sdk/index.html) tools Verzeichnis entpacken
3. Samsung per USB anschließen (im USB Debug Modus)
4. Folgende Befehlskette eingeben

adb push busybox /system/xbin
adb push playlogos1 /sdcard
adb push userinit.sh /sdcard


Nun ist alles für den Speedfix vorbereitet. Nun folgende Kommandos eingeben
adb shell
su
busybox dd if=/dev/zero of=/data/dataimg bs=1024 count=1048576
busybox mknod /dev/loop0 b 7 0
busybox losetup /dev/loop0 /data/dataimg
busybox mkfs.ext2 /dev/loop0
mkdir /data/data1

busybox mount -o remount,rw -t rootfs /
mv /system/bin/playlogos1 /system/bin/playlogosnow
cp /sdcard/playlogos1 /system/bin/playlogos1
cp /sdcard/userinit.sh /system/bin/userinit.sh
chmod 755 /system/bin/playlogos1
chmod 755 /system/bin/userinit.sh
busybox mount -o remount,ro -t rootfs /

reboot

Nun den Quadrant Benchmark laufen lassen-dieser müsste weit über 2000 Punkte sein.

Mehr Infos in dem XDA Thread http://forum.xda-developers.com/showthread.php?t=748596

uff das klingt ja sehr interessant. gibt es schon jemanden, der es getestet hat?

Ja ich ;) Und läuft ohne Probleme

das bedeutet aber, den "alten" speedfix erst mal wieder weg.

und ich lese nur was über playlogos.
Was ist mit dem fetten Data Ordner und Media?

@spline das verschieben geschieht durch das script-vorher werden nur Dateien angepasst um beim bootend as Script auszuführen. Es wird /data/data und /data/dalvik-cache dann verschoben. Und ja erst den alten SDCard Fix rückgängig machen. Es wird auch kein gesonderter Kernel (wie beim SDCard Fix) benötigt-es geht mit jeder Firmware.

habe den alten ext4 Speedfix drauf,
könnte nochmal einer die Aufhebung beschreiben....

ich habe folgendes gemacht:

su (Anfrage bestätigen)
busybox cp -rp /data/data /disk/
busybox mv /data/data /data/data.bak
busybox ln -s /disk/data /data/data
busybox mv /system/media /disk/
busybox ln -s /disk/media /system/media
reboot

Danke für die Info...

und noch eine Frage: was passiert eigentlich bei den neuen Fix (bin des linuxen nicht so mächtig____:-)

Zitat:

---

Zitat von spline

das bedeutet aber, den "alten" speedfix erst mal wieder weg.

---

Sollte eigentlich keine Rolle spielen, wenn ich mir das userinit.sh-Script anschaue. Damit wird beim ersten Boot alles unter /data/data/* in's neue Data-File kopiert, unabhängig davon, ob das effektiv in /data oder unter /sdext oder wie auch immer liegt.
=> Ich probier's einfach mal ;-)

mh, klingt dann ja wirklich Interessant.
Gibts noch mehr freiwillige Tester ;-)

@NeidRider der alte SpeedFix muss soweit rückgängig gemacht werden das die /data/data Dateien wieder vorhanden sind-sonst wird der Symbolische Link kopiert.

Hab's gerade gemäss Anleitung gemacht, ohne vorher den ext4-Speedfix rückgängig zu machen. Alle Daten sind übernommen, nach dem ersten Boot dauert's einfach zuerst mal ziiiiemlich lange, bis das Gerät zackig reagiert (aufgrund des Kopierens der Daten, vermute ich) danach *zoooooooooooooom* ;-)
Quadrant Standard meint dazu: 2288.
Ich lasse die ext4-Partition mal noch auf der SD Karte, falls ich zurück muss, aber der erste Eindruck ist sehr positiv.

Zitat:

---

Zitat von dahool

@NeidRider der alte SpeedFix muss soweit rückgängig gemacht werden das die /data/data Dateien wieder vorhanden sind-sonst wird der Symbolische Link kopiert.

---

Nein. Im Script wird "/data/data/*" kopiert, das sind alle Dateien/Files die unterhalb des Links liegen.
Und der symbolische Link wird dann von /data/data nach /data/olddata umbenannt, auch kein Verlust.

puh eigentlich wollte ich grad zum Sport, aber jetzt macht Ihr mich ja wieder heiss ... ;-)

Einfach nach Anleitung?

SDK Tools Verzeichnis? Im Handy?

Genau, einfach nach Anleitung.
Grundsätzlich musst Du einfach per 'adb' auf's Gerät zugreifen können, da gibt's genügend HowTos im Forum.

Ich habe bei mir dem userinit.sh Script noch eine Zeile zum aushängen der ext4-Partition angehängt ('busybox umount /disk'); der speziell dafür gepatchte Kernel mountet die ja selber beim booten, die braucht's aber dann nicht mehr (und ich vermute, dass das ziemlich am Akku saugt, da die SD-Karte dann immer angehängt ist.)
Sobald ich mal einen Original Kernel finde pappe ich den wieder drauf, im Moment muss es aber dieser Workaround tun (und booten tut man ja sowieso nur alle paar Schaltjahre ;-)

Viel Glück.

aso?
das heisst, es werden nun die Daten einfach nur auf die externe SD Karte verschoben und nicht mehr auf die externe SD ext.4 Partition?

Zitat:

---

Zitat von spline

aso?
das heisst, es werden nun die Daten einfach nur auf die externe SD Karte verschoben und nicht mehr auf die externe SD ext.4 Partition?

---

Nein, noch besser, die Daten bleiben komplett im internen Speicher, unter /data/.

und das soll helfen?

im XDA Thread les ich da was von einer zuvor erstellten ext2 Partition dafür und dann noch dies:

"no need to try ext3/4, they'll slow down ur phone, i've tried them already"

@NeidRider Das ist schon klar. Nur wird dadurch das booten langsamer-weil er beim ersten mal es eben aus der SD Karte holen muss zum kopieren.


Könnte mal jemand das auch ohne und mit autokiller testen. Es geht darum um den highmemkiller Bug einzukreisen-bisher läuft es bei mir ohne sehr gut-auch bei vielen Anwendungen. Ich habe den verdacht, dass der Fehelr wirklich nur im Zusammenspiel mit der exzessiven Nutzung des RFS Dateisystem zusammen hängt.

@splide die Aussage bezieht sich das man nicht das ext3/ext4 Format (journaling) benötigt-sondern das ext2 reicht.

P.S. Heute Abend ändere ich das Script nochmal ab um auch databases zu verschieben-was noch mehr speed bringen soll.

Zitat:

---

Zitat von spline

und das soll helfen?

im XDA Thread les ich da was von einer zuvor erstellten ext2 Partition dafür und dann noch dies:

"no need to try ext3/4, they'll slow down ur phone, i've tried them already"

---

Ja, das hilft, weil:
Er legt ein Image an, innerhalb dessen wird ein ext2 Filesystem angelegt. Darin speichert er dann die Daten. Und das Ganze hängt er über das Loopback-Device ein (das ist so wie wenn Du ein ISO mittels Alcohol oder so mountest).

Zitat:

---

Zitat von dahool

@NeidRider Das ist schon klar. Nur wird dadurch das booten langsamer-weil er beim ersten mal es eben aus der SD Karte holen muss zum kopieren.

---

Das booten ist nur beim ersten Mal langsam, immerhin, da er da prüft ob die zu erstellenden Verzeichnisse bereits vorhanden sind.

Habe mich auch eben gefragt wo das SDK Tools ist...
Gehört das angelegt? Im rootexplorer finde ichs auf jeden fall nicht... :confused:
Bitte um genaue Strukturbeschreibung...
Danke

Stimmt, hab ich auch grad gelesen.
ein ext2 System im Fat32 der internen SD. .. kein Zugriff mehr auf die externe nötig, daher noch schneller.

Da wart ich doch mal auf dahool sein geändertes Script wegen den Datenbanken :-)

@all Bitte mal ansehen und (Typo) Fehler melden (noch nicht auf das Handy spielen) http://www.linux-linux.de/userinit.sh (da ist dann auch databases mit enthalten). Wenn keine Fehelrmeldungen kommen wird das heute Abend in die RAR Datei gepackt

SDK Tools bezieht sich auf den PC.
Ihr müsst ja grundsätzlich das Android SDK auf dem PC/Mac installiert haben, um mit ADB arbeiten zu können.
Schaut sonst mal in den Sammelthread mit Infos, evtl. findet ihr dort die nötigen Infos.

Hi@all

Hab noch keinen Speedfix gemacht nur die JM2 geflasht.
Wenn ich das richtig verstehe, bruach ich jetzt nur die Anleitung vom 1 Thread machen, oder?

Muss man die Daten von der SD Card und die Tel.Daten speichern oder bleibt alles drauf, wie´s ist? (Sry wegen den Fragen, aber hab mich mit SpeedFix noch nicht so beschäftigt)

Danke schon vorweg mal für die Antwort.

Zitat:

---

Zitat von dahool

@all Bitte mal ansehen und (Typo) Fehler melden (noch nicht auf das Handy spielen) http://www.linux-linux.de/userinit.sh (da ist dann auch databases mit enthalten). Wenn keine Fehelrmeldungen kommen wird das heute Abend in die RAR Datei gepackt

---

Zeile 64: databses (2x)
Ansonsten sieht's gut aus.

Allerdings stellt sich mir die Frage, warum /dbdata/databases nach /data verschoben werden sollte. In einer ersten Version des Speedfixes hat man ja /data/data nach /dbdata verschoben, weil das schon massiv schneller war?

@NeidRider Danke!Danke! dir :p Ändere ich gleich ab

Der erste (Modaco) Fix mit verschieben auf /dbdata brachten nach einiger Zeit auch wieder die Lags-das lag an dem verwendeten RFS. Erst mit verschieben auf die (langsame) externe SD Karte wurde das behoben. Der Modaco Fix angewendet und wieder rückgängig gemacht hat auch erst mal keine Lags-weil alle Dateien unter /data wieder an eine Stelle verschoben werden-aber nach einiger Zeit fangen halt wieder die Lag Probleme an.

P.S. Es folgt nachher noch ein anderes Script-damit man /data/app und /data/app-private auch noch in die Loop Datei rein nimmt.

So, habe es auch gewagt mit bestehender Firmware und ext4 Fix. Und es hat geklappt nehm ich an, jedenfalls zeigt mir Quadrant jetzt 2255 Punkte an. Super :)

Hallo,

ich versuche auch, diesen Fix zu installieren. Habe ein gerootetes JM2 Galaxy s. Gerootet habe ich über update.zip. Wenn ich jetzt über adb shell den ersten Befehl eingebe, erhalte ich die Fehlermeldung "Permission denied". Bisher hatte ich alle Befehle immer über die Connectbox eingegeben. Was mache ich falsch? Gibt es hier ein gutes Howto für ADB? Ich habe die SDK installiert auf Win 7 und die tools.rar in den Tools ordner der SDK extrahiert.

Endlich steigt die Wahrscheinlichkeit, dass auch Samsung selbst die Performance-Probleme mit einem Firmware-Upgrade löst! :-)

Die Methode würde doch genau so auch mit FroYo (JP-Firmwares) funktionieren, oder?..

@vygi die Methode ist Firmware unabhängig-also geht auch auf Froyo

//Edit Also die besten Ergebnisse bekomme ich mit /data /app /app-rpivate als Script zu verschieben.... databases brachte eher eine Verlangsamung bei mir. Neue Scripte folgen heute Abend mit /data/app und /data/app-private

Also, ich werde auch mal kurz mein Wissen zu dem Thema kundtun ;)

Der selbst gebastelte Speedfix, den ich jetzt seit einer knappen Woche auf meinem SGS mit JP3 laufen habe basiert auf einer ähnlichen Methode, soll heißen auch über die ersetzte playlogo-Datei (Bootlogo), die dann nebenher noch die das userinit-Script aufruft.

Allerdings arbeite ich noch ähnlich dem "alten" SpeedFix mit einer ext3-Partition auf der MicroSD. Ext2 wurde dabei ausdrücklich nicht empfohlen (auch wenn sie schneller ist), da sie beim Ausschalten des SGS nicht sauber unmounted wird und dadurch die Gefahr bei ext2 groß ist, dass die Dateien darauf beschädigt werden, was im schlimmsten Fall zu einer Bootschleife führt.
Ich weiß nur nicht ob das Risiko ebenfalls besteht so wie die ext-Partition hier eingebunden wird.

Den neuen Indien- und Kanada-Firmwares zufolge scheint Samsung das Lag-Problem ja sogar bereits im Griff zu haben, nur fehlt uns noch das passende europäische Pendant ;)

Mir ist was unschönes aufgefallen:
Seit diesem SpeedFix habe ich keine Notification und Call Töne mehr, nur noch, was ich selber hinzugefügt habe.
Hat das sonst noch jemand (habe das erst seit dem zweiten Reboot).
Versuche mal die Ursache einzugrenzen und das Problem zu lösen...

EDIT: Problem gefunden...
Irgendjemand ;-) hat /system/media auch nach /disk/media gelinkt. Und da ich jetzt das ext4-Filesystem beim booten abhänge... Naja.
Werde /system/media auch mal in's neu geschaffene Filesystem schieben.

Angeblich kommt die Lag Prolematik auch mit dem neuem Fix wieder, vermutlich weil die Quelle im IO-Engpass der internen SD zu suchen ist. Kann das jemand bestätigen?

Zitat:

---

Using this fix for a while - lags returned, and they are unstable. I mean - sometimes it's faster than "standard" SGS, sometimes it freeze more than "standard". It's my main phone, so i've returned back to external card solution.

---

http://forum.xda-developers.com/show...748596&page=29


@Drax
Aus welcher Quelle hast du die Berichte oder Infos bzgl der Lösung des Problems durch Samsung in den Firmwares?

Wenn es stimmt dass das lag problem weg is bei den neuen firmwares, dann warte ich lieber einfach noch ein bisschen ;-)

@NeidRaider

an welcher stelle muss das ('busybox umount /disk'); in die userinit.sh eingefügt werden?

Ich hab's ganz am Ende eingefügt, eine zusätzliche Zeile.

wenn ich anfangen will, die befehle abzutippen, zeigt mir adb immer an failed to copy..... :permission denied

hab das aber vorher noch nie gemacht über adb. weiß jemand wo ich den fehler gemacht hab?

Probier's mal mit "busybox cp" anstelle von "cp".

die erste zeile lautet doch
adb push busybox /system/xbin

ja und wenn ich das eingebe kommt das wie oben beschrieben

Ah so!
Sorry, hatte einen falschen Verdacht.
Um etwas nach /system pushen zu können, musst Du zuerst ein "adb remount" machen; bei mir klappt das allerdings gerade nicht, also ohne Gewähr ;-)