EDIT: I cannot recommend placing the swapfile on /sdcard as I have done here. As discussed below, this will cause problems if you mount the SD card without first shutting down swap. Instead, use an existing ext2/ext3 filesystem (if you have one). If you don't, you have been warned.
Apologies if this was already discussed somewhere; I searched about and aside from a couple threads with too many hundred pages to sift through, I didn't see anything obviously relevant...
There is an alternative method to using an additional ext2/ext3 partition for setting up swap space on an SD card, but I'm not sure what the performance ramifications are (should be insignificant). I set this up on the vfat partition that's mounted as /sdcard (yes, I know the risks behind having swap mounted on the vfat slice -- if you care and have a large enough pre-existing ext2 or ext3 filesystem, go ahead and put the swapfile there instead ):
as root, via adb shell, to make a 24mb swapfile:
Code:
# dd if=/dev/zero of=/sdcard/swapfile.swp bs=1024 count=24576
# mkswap /sdcard/swapfile.swp
# swapon /sdcard/swapfile.swp
Afterwards, "free" should look something like this:
Code:
# free
free
total used free shared buffers
Mem: 98328 96412 1916 0 116
Swap: 24568 0 24568
Total: 122896 96412 26484
I haven't worked out automounting of the swapfile on reboot...I'm still debating if the performance gains are worth the effort to continue, but it looks like there's some potential. Certainly the lag and and "loading" time when going to TouchFlo from another app feel reduced - but I have no empirical evidence to back that up.
Cheers!
Thanks for posting, I will try it using Dude's 1.3rc2. I am also using the ext3 partition.
As far as I know, this is how the Swapper app in the Market works - it places a swap file at the path of your choice (/sdcard/ by default)
Hi There,
I just tried on JF1.51 ADP
I set the swap file on the ext3 partion of the sdcard. It actually seems to help a lot, specially with intensive applications (i.e. copilot live).
I'll test it for a while.
with app2sd it would be possible to modify the script to call the mkswap and swapon command on boot.
Cheers and thanks for the info
Sorry doulbe post
Saiboogu said:
As far as I know, this is how the Swapper app in the Market works - it places a swap file at the path of your choice (/sdcard/ by default)
Click to expand...
Click to collapse
Thanks for that! This does appear to be the case. I hadn't looked for apps in the market -- the various ROM threads are filthy with comments about manually creating a third partition to house swap and I wanted to cleanly illustrate an alternative that relies only on existing partitions.
Swapper looks to potentially be an even easier alternative.
rastacre said:
with app2sd it would be possible to modify the script to call the mkswap and swapon command on boot.
Click to expand...
Click to collapse
After the file is created (via dd) mkswap initializes it as swap space. So long as the file doesn't get deleted/recreated, you shouldn't actually need to re-mkswap it, just swapon it.
Also, it shouldn't be necessary to use Apps2SD to make it mount on boot. It certainly is one way to skin the proverbial cat, but I'm hoping for a more elegant solution...
Cheers!
Yes swapper does the same thing as this but there is an issue here.
When using swapper and you have your swp file set on the sd card and then mount your phone to your computer and then turn off mount your sd card will become corrupt. and you will have to reformat.
With this method its even more of a hassle to mount to your pc cause then you would have to open terminal again and get rid of the swap file.
One fix for this is create a separate linux swap partition on your sd card, and use terminal to mount the swp file on there and all these issues will be resolved.
Only thing now is if someone can figure out how to run the swap script on boot, and everything would be golden
sxfx said:
When using swapper and you have your swp file set on the sd card and then mount your phone to your computer and then turn off mount your sd card will become corrupt. and you will have to reformat.
With this method its even more of a hassle to mount to your pc cause then you would have to open terminal again and get rid of the swap file.
One fix for this is create a separate linux swap partition on your sd card, and use terminal to mount the swp file on there and all these issues will be resolved.
Click to expand...
Click to collapse
And there it is. Wow, that really does do something extremely bad...not sure what though.
After mounting the card in Windows, and then releasing it back to the handset, it did complain about an unreadable SD card. It also suggested that I would need to reformat.
Instead, I just run 'swapoff /sdcard/swapfile.swp ; sync' and then rebooted the phone. No reformatting necessary and subsequently executing 'swapon /sdcard/swapfile.swp' works as well.
Looks like using a swapfile on the vfat partition, anyway, is ... not recommended ... unless a way can be found to programmatically 'swapoff' the swapfile before unmounting the partition.
It appears that this is ONLY a problem if your swapfile exists on the "/sdcard" partition, but that you can still create the file on any other pre-existing ext2/ext3 filesystems (such as an Apps2SD partition, if applicable). I have been unable to recreate this problem with swap mounted on my "/system/sd" slice (/dev/block/mmcblk0p2)...
sxfx said:
Yes swapper does the same thing as this but there is an issue here.
When using swapper and you have your swp file set on the sd card and then mount your phone to your computer and then turn off mount your sd card will become corrupt. and you will have to reformat.
With this method its even more of a hassle to mount to your pc cause then you would have to open terminal again and get rid of the swap file.
One fix for this is create a separate linux swap partition on your sd card, and use terminal to mount the swp file on there and all these issues will be resolved.
Only thing now is if someone can figure out how to run the swap script on boot, and everything would be golden
Click to expand...
Click to collapse
That's exactly what I was looking for.
What's the command I should use in terminal to push the swap file to my swap partition?
mholger said:
And there it is. Wow, that really does do something extremely bad...not sure what though.
After mounting the card in Windows, and then releasing it back to the handset, it did complain about an unreadable SD card. It also suggested that I would need to reformat.
Instead, I just run 'swapoff /sdcard/swapfile.swp ; sync' and then rebooted the phone. No reformatting necessary and subsequently executing 'swapon /sdcard/swapfile.swp' works as well.
Looks like using a swapfile on the vfat partition, anyway, is ... not recommended ... unless a way can be found to programmatically 'swapoff' the swapfile before unmounting the partition.
It appears that this is ONLY a problem if your swapfile exists on the "/sdcard" partition, but that you can still create the file on any other pre-existing ext2/ext3 filesystems (such as an Apps2SD partition, if applicable). I have been unable to recreate this problem with swap mounted on my "/system/sd" slice (/dev/block/mmcblk0p2)...
Click to expand...
Click to collapse
Yes, best bet is to not put it on the vfat partition. Since the mmcblk0p2 does not become mounted/unmounted, it is better to put it on there. I've corrupted my card twice putting it on the vfat. Even better is to create a swap partition, on mmcblk0p3
andonnguyen said:
Yes, best bet is to not put it on the vfat partition. Since the mmcblk0p2 does not become mounted/unmounted, it is better to put it on there. I've corrupted my card twice putting it on the vfat. Even better is to create a swap partition, on mmcblk0p3
Click to expand...
Click to collapse
Agreed.
Original post has been ... amended.
So, question for anyone who knows...
I'm running JACHero 2.1, so I don't know if this applies to other images, but this build has both loopback FS support and mke2fs via busybox - and I have massive space available in both /data and /cache, so ...
Code:
dd if=/dev/zero of=/data/swapfile.e2fs bs=1024 count=16384
mke2fs /data/swapfile.e2fs
mkdir /data/swap
mount -t ext2 -o loop,rw /data/swapfile.e2fs /data/swap
dd if=/dev/zero of=/data/swap/swapfile bs=1024 count=16380
mkswap /data/swap/swapfile
swapon /data/swap/swapfile
Apparently mounting swapfiles directly off of yaffs2 partitions is verboten - swapon won't touch it. This overcomes that by using the loopback fs to mount a file as an ext2 partition, and as swapon will use a swapfile on an ext2 partition ... we can have swap in intmem. Which should be faster than the SD card as well as having a much larger read/write lifecycle than SD does.
The question is whether or not there's a performance increase to be had. If placing a swapfile on either /data or /cache actually detracts from overall system memory (it doesn't appear to) then the whole point is moot...
But if it doesn't, then performance should be improved over swapping to SD. My short-term experience is to the contrary, however... anyone have any clue why this might be?
a class 6 sdcard is faster than the internal flash.
mholger said:
So, question for anyone who knows...
I'm running JACHero 2.1, so I don't know if this applies to other images, but this build has both loopback FS support and mke2fs via busybox - and I have massive space available in both /data and /cache, so ...
Code:
dd if=/dev/zero of=/data/swapfile.e2fs bs=1024 count=16384
mke2fs /data/swapfile.e2fs
mkdir /data/swap
mount -t ext2 -o loop,rw /data/swapfile.e2fs /data/swap
dd if=/dev/zero of=/data/swap/swapfile bs=1024 count=16380
mkswap /data/swap/swapfile
swapon /data/swap/swapfile
Apparently mounting swapfiles directly off of yaffs2 partitions is verboten - swapon won't touch it. This overcomes that by using the loopback fs to mount a file as an ext2 partition, and as swapon will use a swapfile on an ext2 partition ... we can have swap in intmem. Which should be faster than the SD card as well as having a much larger read/write lifecycle than SD does.
The question is whether or not there's a performance increase to be had. If placing a swapfile on either /data or /cache actually detracts from overall system memory (it doesn't appear to) then the whole point is moot...
But if it doesn't, then performance should be improved over swapping to SD. My short-term experience is to the contrary, however... anyone have any clue why this might be?
Click to expand...
Click to collapse
mholger said:
So, question for anyone who knows...
I'm running JACHero 2.1, so I don't know if this applies to other images, but this build has both loopback FS support and mke2fs via busybox - and I have massive space available in both /data and /cache, so ...
Code:
dd if=/dev/zero of=/data/swapfile.e2fs bs=1024 count=16384
mke2fs /data/swapfile.e2fs
mkdir /data/swap
mount -t ext2 -o loop,rw /data/swapfile.e2fs /data/swap
dd if=/dev/zero of=/data/swap/swapfile bs=1024 count=16380
mkswap /data/swap/swapfile
swapon /data/swap/swapfile
Apparently mounting swapfiles directly off of yaffs2 partitions is verboten - swapon won't touch it. This overcomes that by using the loopback fs to mount a file as an ext2 partition, and as swapon will use a swapfile on an ext2 partition ... we can have swap in intmem. Which should be faster than the SD card as well as having a much larger read/write lifecycle than SD does.
The question is whether or not there's a performance increase to be had. If placing a swapfile on either /data or /cache actually detracts from overall system memory (it doesn't appear to) then the whole point is moot...
But if it doesn't, then performance should be improved over swapping to SD. My short-term experience is to the contrary, however... anyone have any clue why this might be?
Click to expand...
Click to collapse
it's probably not good to place a swap on your internal memory, just in case swap does lead to fs or disk corruption in the future (further testing is needed). still best case scenario is to create a linux-swap on your sdcard and:
mkswap /dev/block/mmcblk0p3
swapon /dev/block/mmcblk0p3
echo 30 > /proc/sys/vm/swappiness
andonnguyen said:
it's probably not good to place a swap on your internal memory, just in case swap does lead to fs or disk corruption in the future (further testing is needed). still best case scenario is to create a linux-swap on your sdcard
Click to expand...
Click to collapse
I'm nominally inclined to disagree with this. Swapfiles shouldn't pose any risk in terms of fs or disk corruption on a non-removable filesystem -- it's been around in linux long enough that someone would have had to critically break Android to cause this to be a problem. On the other hand, corruption issues are rampant on the SD cards primarily as a result of dirty dismounts -- which can lead to other system problems as well. Combined with the theoretical** increase in read/write cycles on the flash, if performance were equal it would seem sensible to place as much swap internally as possible. As it turns out, things aren't exactly equal, however..
**I'm quite frequently wrong, as we'll see below, and this is a particularly salient point to disprove me on if you're so inclined.
dwang said:
a class 6 sdcard is faster than the internal flash.
Click to expand...
Click to collapse
I find this hard to believe, so I run tests.
The results are downright astonishing. At least to me. Guess I'm used to system memory being faster even than a good SSD if for no better reason than architectural limitations...
Code:
# time dd if=/dev/zero of=/system/sd/test.mholger bs=2048 count=8192
time dd if=/dev/zero of=/system/sd/test.mholger bs=2048 count=8192
8192+0 records in
8192+0 records out
16777216 bytes transferred in 1.522 secs (11023137 bytes/sec)
real 0m 1.61s
user 0m 0.05s
sys 0m 0.70s
# time dd if=/dev/zero of=/data/test.mholger bs=2048 count=8192
time dd if=/dev/zero of=/data/test.mholger bs=2048 count=8192
8192+0 records in
8192+0 records out
16777216 bytes transferred in 9.162 secs (1831173 bytes/sec)
real 0m 10.48s
user 0m 0.05s
sys 0m 2.90s
# time dd if=/dev/zero of=/system/sd/test.mholger bs=1024 count=8192
time dd if=/dev/zero of=/system/sd/test.mholger bs=1024 count=8192
8192+0 records in
8192+0 records out
8388608 bytes transferred in 0.504 secs (16644063 bytes/sec)
real 0m 0.56s
user 0m 0.05s
sys 0m 0.47s
# time dd if=/dev/zero of=/data/test.mholger bs=1024 count=8192
time dd if=/dev/zero of=/data/test.mholger bs=1024 count=8192
8192+0 records in
8192+0 records out
8388608 bytes transferred in 4.096 secs (2048000 bytes/sec)
real 0m 5.40s
user 0m 0.05s
sys 0m 1.13s
You get the idea. Writing to SD is 2x to 4x faster at the system level, and can exceed 5x performance against the wall clock! f* me!
andonnguyen said:
it's probably not good to place a swap on your internal memory, just in case swap does lead to fs or disk corruption in the future (further testing is needed). still best case scenario is to create a linux-swap on your sdcard and:
mkswap /dev/block/mmcblk0p3
swapon /dev/block/mmcblk0p3
echo 30 > /proc/sys/vm/swappiness
Click to expand...
Click to collapse
any idea on writing this into a script so it executes every time your phone reboots?
Nice... I knew it was faster, but I didn't know how fast. Now we have some actual numbers. I wonder what the read performance is like.
here's the results writing to RAM /dev (I believe tmpfs is RAM).
How did you get this line printed out?
16777216 bytes transferred in 1.522 secs (11023137 bytes/sec)
EDIT: Ok you used toolbox dd and I used busybox dd
Code:
time dd if=/dev/zero of=/dev/test.mholger bs=2048 count=8192
time dd if=/dev/zero of=/dev/test.mholger bs=2048 count=8192
8192+0 records in
8192+0 records out
real 0m 0.35s
user 0m 0.02s
sys 0m 0.20s
# time dd if=/dev/zero of=/dev/test.mholger bs=2048 count=8192
time dd if=/dev/zero of=/dev/test.mholger bs=2048 count=8192
8192+0 records in
8192+0 records out
real 0m 0.32s
user 0m 0.04s
sys 0m 0.28s
# time dd if=/dev/zero of=/dev/test.mholger bs=2048 count=8192
time dd if=/dev/zero of=/dev/test.mholger bs=2048 count=8192
8192+0 records in
8192+0 records out
real 0m 0.27s
user 0m 0.02s
sys 0m 0.26s
#
mholger said:
I find this hard to believe, so I run tests.
The results are downright astonishing. At least to me. Guess I'm used to system memory being faster even than a good SSD if for no better reason than architectural limitations...
You get the idea. Writing to SD is 2x to 4x faster at the system level, and can exceed 5x performance against the wall clock! f* me!
Click to expand...
Click to collapse
Another good idea I saw in another thread is to use swapper and set the location to system/sd/swapfilename
This way you wont have to go through the hassle of creating a swap partition, and swapper runs on boot ..
mholger said:
I'm nominally inclined to disagree with this. Swapfiles shouldn't pose any risk in terms of fs or disk corruption on a non-removable filesystem -- it's been around in linux long enough that someone would have had to critically break Android to cause this to be a problem. On the other hand, corruption issues are rampant on the SD cards primarily as a result of dirty dismounts -- which can lead to other system problems as well. Combined with the theoretical** increase in read/write cycles on the flash, if performance were equal it would seem sensible to place as much swap internally as possible. As it turns out, things aren't exactly equal, however..
**I'm quite frequently wrong, as we'll see below, and this is a particularly salient point to disprove me on if you're so inclined.
I find this hard to believe, so I run tests.
The results are downright astonishing. At least to me. Guess I'm used to system memory being faster even than a good SSD if for no better reason than architectural limitations...
Code:
# time dd if=/dev/zero of=/system/sd/test.mholger bs=2048 count=8192
time dd if=/dev/zero of=/system/sd/test.mholger bs=2048 count=8192
8192+0 records in
8192+0 records out
16777216 bytes transferred in 1.522 secs (11023137 bytes/sec)
real 0m 1.61s
user 0m 0.05s
sys 0m 0.70s
# time dd if=/dev/zero of=/data/test.mholger bs=2048 count=8192
time dd if=/dev/zero of=/data/test.mholger bs=2048 count=8192
8192+0 records in
8192+0 records out
16777216 bytes transferred in 9.162 secs (1831173 bytes/sec)
real 0m 10.48s
user 0m 0.05s
sys 0m 2.90s
# time dd if=/dev/zero of=/system/sd/test.mholger bs=1024 count=8192
time dd if=/dev/zero of=/system/sd/test.mholger bs=1024 count=8192
8192+0 records in
8192+0 records out
8388608 bytes transferred in 0.504 secs (16644063 bytes/sec)
real 0m 0.56s
user 0m 0.05s
sys 0m 0.47s
# time dd if=/dev/zero of=/data/test.mholger bs=1024 count=8192
time dd if=/dev/zero of=/data/test.mholger bs=1024 count=8192
8192+0 records in
8192+0 records out
8388608 bytes transferred in 4.096 secs (2048000 bytes/sec)
real 0m 5.40s
user 0m 0.05s
sys 0m 1.13s
You get the idea. Writing to SD is 2x to 4x faster at the system level, and can exceed 5x performance against the wall clock! f* me!
Click to expand...
Click to collapse
very nice sir
mholger said:
EDIT: I cannot recommend placing the swapfile on /sdcard as I have done here. As discussed below, this will cause problems if you mount the SD card without first shutting down swap. Instead, use an existing ext2/ext3 filesystem (if you have one). If you don't, you have been warned.
Apologies if this was already discussed somewhere; I searched about and aside from a couple threads with too many hundred pages to sift through, I didn't see anything obviously relevant...
There is an alternative method to using an additional ext2/ext3 partition for setting up swap space on an SD card, but I'm not sure what the performance ramifications are (should be insignificant). I set this up on the vfat partition that's mounted as /sdcard (yes, I know the risks behind having swap mounted on the vfat slice -- if you care and have a large enough pre-existing ext2 or ext3 filesystem, go ahead and put the swapfile there instead ):
as root, via adb shell, to make a 24mb swapfile:
Code:
# dd if=/dev/zero of=/sdcard/swapfile.swp bs=1024 count=24576
# mkswap /sdcard/swapfile.swp
# swapon /sdcard/swapfile.swp
Afterwards, "free" should look something like this:
Code:
# free
free
total used free shared buffers
Mem: 98328 96412 1916 0 116
Swap: 24568 0 24568
Total: 122896 96412 26484
I haven't worked out automounting of the swapfile on reboot...I'm still debating if the performance gains are worth the effort to continue, but it looks like there's some potential. Certainly the lag and and "loading" time when going to TouchFlo from another app feel reduced - but I have no empirical evidence to back that up.
Cheers!
Click to expand...
Click to collapse
jacHEROski does this automatically using a linux-swap partition - that way your sdcard never gets corrupted on mount. It's also more reliable.
jacHEROski_Experimental also does it.
check out my a2sd.sh in /system/bin/ for more info on how to do it.
So I tried to clear my GPS EFS and it did more than that. On boot, instead of seeing the splash screen, I get colorbars and skateboards and then it jumps to the splash animation. I flashed the HBOOT, Radio, Orig and CWM Recovery, boot splash, boot animation with no change. I suppose I could flash the ROM again, but it boots fine. Really, I don't need a fix, just posting this in case someone else has the same problem.
update: I ended up flashing the original rom image and then flashing back
What I did to cause the problem, the efs batch didn't appear to run correctly, so I ran it manually as well.
C:\TEMP\ADB>adb push vision_wipe_efs /data/local/tmp/
2408 KB/s (577228 bytes in 0.234s)
C:\TEMP\ADB>adb shell
# su
su
# stop rmt_storage
stop rmt_storage
# chmod 777 /data/local/tmp/vision_wipe_efs
chmod 777 /data/local/tmp/vision_wipe_efs
# /data/local/tmp/vision_wipe_efs
/data/local/tmp/vision_wipe_efs
Backing up partition /dev/block/mmcblk0p13 to /sdcard/part13backup-1312554352.bin ...
Backing up partition /dev/block/mmcblk0p14 to /sdcard/part14backup-1312554352.bin ...
Wiping partition /dev/block/mmcblk0p13...
Error writing output file.
# dd if=/dev/zero of=/dev/block/mmcblk0p13
dd if=/dev/zero of=/dev/block/mmcblk0p13
/dev/block/mmcblk0p13: write error: No space left on device
65+0 records in
64+0 records out
32768 bytes transferred in 0.010 secs (3276800 bytes/sec)
# dd if=/dev/zero of=/dev/block/mmcblk0p14
dd if=/dev/zero of=/dev/block/mmcblk0p14
/dev/block/mmcblk0p14: write error: No space left on device
12289+0 records in
12288+0 records out
6291456 bytes transferred in 2.728 secs (2306252 bytes/sec)
Thanks,
-mix
Please help, I have the same issue I tried to wipe efs data because my gps is not working and now I get the same issue... but is still booting, and because I'm flashoolic I dislike to have any little or huge issue... So can someone please help me ?
Hi there,
I'm working at creating a solution for JTAG repair on the SGS III USC model and I'm in need of a SCH-R530 SBL dumps and a few other zones. I need a rooted user to simply perform the following command from a terminal on the phone, or while using ADB SHELL under the su user. Once at the command line issue this command, then simply upload the files which end up on your sdcard to me here. That's it!
Thanks in advance!
Code:
dd if=/dev/block/mmcblk0p2 of=/sdcard/sbl1 bs=4096
dd if=/dev/block/mmcblk0p3 of=/sdcard/sbl2 bs=4096
dd if=/dev/block/mmcblk0p4 of=/sdcard/sbl3 bs=4096
dd if=/dev/block/mmcblk0p5 of=/sdcard/aboot bs=4096
dd if=/dev/block/mmcblk0p6 of=/sdcard/rpm bs=4096
dd if=/dev/block/mmcblk0p7 of=/sdcard/boot bs=4096
dd if=/dev/block/mmcblk0p8 of=/sdcard/tz bs=4096
dd if=/dev/block/mmcblk0p9 of=/sdcard/pad bs=4096
dd if=/dev/block/mmcblk0p10 of=/sdcard/param bs=4096
dd if=/dev/block/mmcblk0p18 of=/sdcard/recovery bs=4096
Request fulfilled thanks a lot!
SGS 3 USC Files
If anyone has these files I would also greatly appreciate if you can forward the to me.
I have the wires soldered and ready to flash but this specific SGS 3 from USC is not supported. Thank in advance.
dead r530
coronelac said:
If anyone has these files I would also greatly appreciate if you can forward the to me.
I have the wires soldered and ready to flash but this specific SGS 3 from USC is not supported. Thank in advance.
Click to expand...
Click to collapse
i have also a hard bricked r530 its only detect in pc as a quallcom com port plz share how to unbrick it
bro are you able to revive it from the qualcomm com port? or jtag?