RFS Dateisystem austauschen gegen ext Dateiformat (LagFix)

[Bierfreund]

ext2 is halt super schnell weils kein journaling unterstützt, ext4 kann journaling und ist somit sicherer.

Dann versteh ich nicht, warum man nicht das schnellere ext2 verwendet.

 

[ninjafox]

Dann versteh ich nicht, warum man nicht das schnellere ext2 verwendet.

weil da die gefahr aufgrund der fehlenden journaling funktion um einiges höher ist durch einen fehler daten zu verlieren oder sogar das gesamte dateisystem lahmzulegen.

außerdem bringt der "speed" des ext2 dateisystems dir nur im quadrant benchmark einen höheren wert, den unterschied zum ext4 wert kann man sich im alltagsgebraucht aber in die haare schmieren.

 

[hachi]

weil da die gefahr aufgrund der fehlenden journaling funktion um einiges höher ist durch einen fehler daten zu verlieren oder sogar das gesamte dateisystem lahmzulegen.

außerdem bringt der "speed" des ext2 dateisystems dir nur im quadrant benchmark einen höheren wert, den unterschied zum ext4 wert kann man sich im alltagsgebraucht aber in die haare schmieren.

das is so nicht korrekt...
"nur im quadrant".. wenn man etwas gespür dafür hat merkt man sehr wohl das alles etwas flotter is

 

[fighting4fun]

@stepping das schlimmste was passieren kann ist ein re-flash der firmware. unbrauchbar (dauerhaft) wird das handy nicht

Jo dachte ich mir au grad ^^ weil der Kernel ja geflasht wird..

 

[cyorps]

Dann versteh ich nicht, warum man nicht das schnellere ext2 verwendet.

Es enthält neben dem genannten Journal noch folgende Verbesserungen:
- Die Datenblöcke werden zusammengefasst und nicht wie bei ext2/3 in kleinen Blöcken reserviert
- Die Daten werden mit größeren Datenblöcken geschrieben, was die Durchsatzrate steigert
- Nanosekunden genaue Zeitstempel der Datenblöcke
-> Das sind einige Sachen, die letztendlich zu einem schnelleren Datenzugriff als mit ext2 führen.

 

[fighting4fun]

das is so nicht korrekt...
"nur im quadrant".. wenn man etwas gespür dafür hat merkt man sehr wohl das alles etwas flotter is

Jop ^^

P.S. ich hab kein Problem oder Bug mit APN... hab die JM7

PPS trotz Mediascan unglaublich schnell

 

[cyorps]

Habe es gerade einmal ausgetestet. Irgendwas mache ich noch falsch. Denn bei mir läuft dieses Fix weder mit JM6 noch mit JM7. Ich habe es mit der Odin-Variante probiert. Hier habe ich die Datei von der angegeben Seite heruntergeladen und als PDA, ohne PIT und Re-Partition geflasht. Der Restart kommt und Odin sagt, dass alles bestens gelaufen ist. Wenn ich nun das SGS starte, sehe die ich die Bootanimation und danach bleibt das Display schwarz. Was mache ich noch falsch?

 

[stepping]

@stepping das schlimmste was passieren kann ist ein re-flash der firmware. unbrauchbar (dauerhaft) wird das handy nicht

Auf welche Firmware kann denn geflashed werden, wenn es einen fehlerhaften Versuch gegeben hat, eine neue Firmware auf das auf ein ext4 geändertes Galaxy zu flashen? Die üblichen Firmwares lassen sich doch nur auf das Samsung-Format flashen.

 

[cyorps]

@stepping
Ich konnte einfach eine andere Firmware flashen und das war's. Beispielhaft: JM7->Fix hat nicht funktioniert->nochmal JM7->Fix hat nicht funktioniert->JM6... war kein Problem. Das System lief nach dem Flash wieder normal (bevor ich es mir freiwillig wieder zerschossen hatte).

 

[stepping]

Eine gute Nachricht!
Wenn ich wieder zu Hause bin schaue ich mal nach, woher ich die Info hatte, dass das zu Problemen geführt haben soll.

Edit:
Du hast aber noch nicht nach einem erfolgreichen VoodoFix eine andere Firmware geflashed, oder? Das ist ja meine Warnung gewesen.

 

[cyorps]

Vielleicht hilft dir da der Beitrag 311 im entsprechenden XDA-Thread weiter.

 

[fighting4fun]

Eine gute Nachricht!
Wenn ich wieder zu Hause bin schaue ich mal nach, woher ich die Info hatte, dass das zu Problemen geführt haben soll.

Edit:
Du hast aber noch nicht nach einem erfolgreichen VoodoFix eine andere Firmware geflashed, oder? Das ist ja meine Warnung gewesen.

(Dann kann ich Entwarnung geben... mit nem NEUflash wird der Kernel auch neu geschrieben.)
Komisch?

P. S. JM7 funktioniert super... das SGS braucht beim erstenmal starten aber länger...

 

[cyorps]

War der Bildschirm da dunkel oder hast du das "leuchtende S" sehen können?

 

[fighting4fun]

War der Bildschirm da dunkel oder hast du das "leuchtende S" sehen können?

Dunkel... aber vllt für ne Minute

 

[cyorps]

Also ich habe den ganzen Spaß jetzt nochmal ohne Sim und externer SD probiert. Damit hat es dann funktioniert.

 

[MrBusiness]

(Dann kann ich Entwarnung geben... mit nem NEUflash wird der Kernel auch neu geschrieben.)
Komisch?
...

Ist das auch so von dir selbst getestet? Bei XDA sagen sie extra, dass das alle dachten, aber leider wundersamerweise nicht so ist!

 

[fighting4fun]

Ich musste neuflashen... und bei mir geht alles o.O... aber wenn die bei den devs das anderst sagten macht das ruhig anders...

 

[gokpog]

Was ich mir direkt vorstellen könnte ist, dass du nach dem voodoo Fix eine ext4 /data Partition hast und danach eine andere Firmware drüber klatschst, deren Kernel kein ext4 kennt. Da hätte ich auch Probleme erwartet. Wenn das problemlos geht, umso besser.

 

[dahool]

Da viel Unwissenheit zu dem LagFix im Umlauf ist-mal zum selber lesen das wichtigste was der Fix macht:

PATH=/bin:/sbin:/usr/bin/:/usr/sbin

data_archive='/sdcard/voodoo_user-data.tar'
protect_image='/res/mmcblk0p2_protectionmode.img.bz2'

alias mount_data_ext4="mount -t ext4 -o noatime,nodiratime /dev/block/mmcblk0p4 /data"
alias mount_data_rfs="mount -t rfs -o nosuid,nodev,check=no /dev/block/mmcblk0p2 /data"
alias mount_sdcard="mount -t vfat -o utf8 /dev/block/mmcblk0p1 /sdcard"
alias mount_cache="mount -t rfs -o nosuid,nodev,check=no /dev/block/stl11 /cache"
alias mount_dbdata="mount -t rfs -o nosuid,nodev,check=no /dev/block/stl10 /dbdata"

alias make_backup="tar cf $data_archive /data /dbdata "
alias restore_backup="rm -rf /dbdata/*; tar xf $data_archive && rm $data_archive"

alias ext4_check="dumpe2fs -h /dev/block/mmcblk0p4"


model=""
detect_supported_model() {
# read the actual MBR
dd if=/dev/block/mmcblk0 of=/tmp/original.mbr bs=512 count=1

cd /res/mbr_stock
for x in * ; do
if cmp $x /tmp/original.mbr; then
model=$x
continue
fi
done

log "model detected : $model"
cd /
}

set_our_partitions() {
log "set our partitions"
cat /res/mbr_fixed/$model > /dev/block/mmcblk0
sfdisk -R /dev/block/mmcblk0
}

set_samsung_partitions() {
log "set Samsung partitions"
cat /res/mbr_stock/$model > /dev/block/mmcblk0
sfdisk -R /dev/block/mmcblk0
}

fast_wipe_ext4_and_build_rfs() {
# re-write an almost empty rfs partition
# fast wipe :
# 5 first MB
bunzip2 -c $protect_image \
| dd ibs=1024 count=5k of=/dev/block/mmcblk0p2
# 10MB around the 220MB limit
bunzip2 -c $protect_image \
| dd ibs=1024 obs=1024 skip=215k seek=215k count=10k \
of=/dev/block/mmcblk0p2
}

make_backup_conditional() {
# create a backup only if there is not already one that looks valid here
if ! tar tf $data_archive \
data/data/com.android.settings \
dbdata/databases/com.android.providers.settings; then
make_backup
fi
}

check_free() {
mount -t proc proc /proc
# read free space on internal SD
target_free=`df /sdcard | awk '/\/sdcard$/ {print $2}'`
# read space used by data we need to save
space_needed=$((`df /data | awk '/ \/data$/ {print $3}'` \
+ `df /dbdata | awk '/ \/dbdata$/ {print $3}'`))
log "free space : $target_free"
log "space needed : $space_needed"
return `test "$target_free" -ge "$space_needed"`
}


log() {
log="Voodoo lagfix: $1"
logs="$logs / "`date '+%Y-%m-%d %H:%M:%S '`$log
echo $log >> /log
}

letsgo() {
log "running init !"
# dump logs to the sdcard
echo $logs >> /sdcard/log
umount /sdcard

# workaround for T-Mobile Vibrant crappy workarounds
if test "$model" = "16GB-tmo-vibrant"; then
cat /tmp/original.mbr > /dev/block/mmcblk0
fi

exec /sbin/init
}


# insmod required modules
insmod /lib/modules/fsr.ko
insmod /lib/modules/fsr_stl.ko
insmod /lib/modules/rfs_glue.ko
insmod /lib/modules/rfs_fat.ko
insmod /lib/modules/j4fs.ko
insmod /lib/modules/dpram.ko


# hardware-detection
detect_supported_model
if test "$model" = "" ; then
# model not supported
log "this model is not supported"
mount_data_rfs
letsgo
fi

# detect the MASTER_CLEAR intent command
# this append when you choose to wipe everything from the phone settings,
# or when you type *2767*3855# (Factory Reset, datas + SDs wipe)
mount_cache
if test -f /cache/recovery/command; then

if fgrep -- '--wipe_data' /cache/recovery/command; then
log "MASTER_CLEAR mode"
set_our_partitions
# if we are in this mode, we still have to wipe ext4 partition start
set_samsung_partitions
# recovery will find Samsung's partition, will wipe them and be happy !
fast_wipe_ext4_and_build_rfs
umount /cache
letsgo
fi

fi
umount /cache

# first : read instruction from sdcard and do it !
set_our_partitions
mount_sdcard
if test -f /sdcard/disable-lagfix; then

if ext4_check ; then

log "lag fix disabled and ext4 detected"
# ext4 partition detected, let's convert it back to rfs :'(
# mount ressources
mount_data_ext4
mount_dbdata

log "run backup of ext4 /data"

# check if there is enough free space for migration or cancel
# and boot
if ! check_free; then
log "not enough space to migrate from ext4 to rfs"
set_our_partitions
mount_data_ext4
letsgo
fi

make_backup_conditional

# umount mmcblk0 ressources
umount /dbdata
umount /sdcard
umount /data

# restore Samsung's partition layout on the internal SD
set_samsung_partitions

fast_wipe_ext4_and_build_rfs

# remove the gigantic protection_file
log "mount rfs /data"
mount_data_rfs
rm /data/protection_file

# restore the data archived
mount_sdcard
log "restore backup on rfs /data"
restore_backup
umount /sdcard

else

# in this case, we did not detect any valid ext4 partition
# hopefully this is because mmcblk0p2 contains a valid rfs /data
log "lag fix disabled, rfs present"
umount /sdcard
set_samsung_partitions
log "mount /data as rfs"
mount_data_rfs

fi

# now we know that /data is in RFS anyway. let's fire init !
letsgo

fi
umount /sdcard

# Voodoo lagfix is enabled
# detect if the data partition is in ext* format
if ! ext4_check ; then

log "no ext4 partition detected"
# no ext4 partition detected, we will convert to ext4
# for that we first need to restore Samsung's partition table
set_samsung_partitions

# mount ressources we need
log "mount ressources to backup"
mount_data_rfs
mount_dbdata
mount_sdcard

# check if there is enough free space for migration or cancel
# and boot
if ! check_free; then
log "not enough space to migrate from rfs to ext4"
set_samsung_partitions
mount_data_rfs
letsgo
fi

# run the backup operation
log "run the backup operation"
if ! test -f /data/protection_file; then
make_backup_conditional
else
# something's wrong
log "error: protection file present in rfs but no ext4 data"
log "let's hope that a backup is still present"
fi


# umount mmcblk0 ressources
umount /sdcard
umount /data

# write the fake protection file on mmcblk0p2, just in case
log "write the fake protection file on mmcblk0p2, just in case"
bunzip2 -c $protect_image \
| dd ibs=1024 count=5k of=/dev/block/mmcblk0p2

# set our partitions back
set_our_partitions

# build the ext4 filesystem
log "build the ext4 filesystem"

# (empty) /etc/mtab is required for this mkfs.ext4
mkfs.ext4 -F /dev/block/mmcblk0p4
tune2fs -c 0 -i 0 -m 0 /dev/block/mmcblk0p4

mount_data_ext4
mount_sdcard

# restore the data archived
restore_backup

# clean all these mounts
log "umount what will be re-mounted by Samsung's Android init"
umount /dbdata
umount /sdcard

else

# seems that we have a ext4 partition just mount it
log "ext4 detected, mounting it!"
mount_data_ext4

fi

# run Samsung's Android init
letsgo

Das Problem was ein User bei XDA Angesprochen hatte-ist nicht ganz richtig. Das obige Script hat einen Fehler bei der Abfrage ob der Fix schon angewendet wurde. Bei abermaligen installieren des Fixes kann es zu Problemen kommen-die aber immer durch das Aufspielen der Firmware wieder behoben werden kann.

 

[ElGreco]

Ich hab denn Fix jetzt angewendet, jetzt läuft das Teil endlich wie es soll!! Sagt mal wie bekomme ich, falls ich eine andere Firm installieren will, denn Fix wieder runter?? Einfach einen leeren Ordner - uninstall_lagfix erstellen und neu booten??