Hi all,
I've been pondering the whole "apps on sdcard" thing since I got my 16Gb microsdhc card (class 2, so 2MB/s, the slowest), I've even made a 4GB ext2 partition ready for it.
So I've finally got around to looking at the data partition to see what I can do.
Now firstly plenty of people refer to the phones "memory" which isn't very useful really, since we don't have any fixed disks it is all "memory" at the hardware level but "system memory" is different to the memory that is only ever used as storage.
So, The /data partition is on the NAND flash that the G1 has even without an sdcard installed, the larger directories seem to be:
Code:
/data/data #App data, 28MB on my system
/data/app # non system apps, 12MB on my system
/data/app-private # protected apps, 266kB on my system
/data/dalvik-cache # The compiled .dex files for _all_ installed apps, 10MB on my system
So, apps are found in either /system/app /data/app or /data/app-private I wonder if there's anywhere else that android looks by default?
I also can't help but wonder if I should move the davlik-cache folder. Common wisdom is that it would be much slower, especially on a class2 microsdhc so I decided to run a little test
Code:
dd if=/dev/urandom of=tst0.bin bs=1M count=1
date
cp tst0.bin tst1.bin
rm tst0.bin
cp tst1.bin tst2.bin
rm tst1.bin
cp tst2.bin tst3.bin
rm tst2.bin
cp tst3.bin tst4.bin
rm tst3.bin
cp tst4.bin tst5.bin
rm tst4.bin
cp tst5.bin tst6.bin
rm tst5.bin
cp tst6.bin tst7.bin
rm tst6.bin
cp tst7.bin tst8.bin
rm tst7.bin
cp tst8.bin tst9.bin
rm tst8.bin
date
Executing this in /sdcard/ had it complete in about a second which seems to be faster that should be possible so there may well be aggressive write and read caching going on there. Having said that 2MB/s is the minimum speed for the card.
However, doing the same in /data/ took 21 seconds, that's about 0.5MB/sec so I'm wondering if there really are any speed problems running as much as possible from the sdcard.
I suspect your suspicion of aggressive SD caching is correct.
If that were the case, you have measured only the speed of the cache.
A small scenario: Let's say your phone shuts down, all apps are terminated and write final stuff in /data/. Then, the writing process is being cached (the parameter in /etc/fstab is "nosync" I think). But before the cache is being written (by pdflush), the power would go away! Then the data would be lost, possibly requiring a reinstall of the app.
As to your command, I think it's a mistake to define the blocksize as 1 MB and the count as 1. That way, 1 MB is first being cached by dd into one block which is then written. (That just occured to me.)
I just did:
Code:
$ su
# time dd if=/dev/urandom of=/sdcard/random.bin bs=1 count=1024000
and the output was:
Code:
1024000+0 records in
1024000+0 records out
real 0m 49.50s
user 0m 3.46s
sys 0m 44.70s
What's yours?
Edit: I forget the important thing:
Code:
$ su
# time dd if=/dev/urandom of=/data/random.bin bs=1 count=1024000
1024000+0 records in
1024000+0 records out
real 0m 54.90s
user 0m 4.71s
sys 0m 45.13s
It seems to be about the same speed on my device.
SilentMobius said:
I've been pondering the whole "apps on sdcard" thing since I got my 16Gb microsdhc card (class 2, so 2MB/s, the slowest), I've even made a 4GB ext2 partition ready for it.
Click to expand...
Click to collapse
your partition is too large for EXT2 and will not work properly .. you need to size it 2G or less .. you really shouldn't need anything above 500M
LucidREM said:
your partition is too large for EXT2 and will not work properly .. you need to size it 2G or less .. you really shouldn't need anything above 500M
Click to expand...
Click to collapse
Really? I was under the impression that ext2 could go a lot larger than that, there were 2GB file size limits under 2.2 kernels and older libc's but I wasn't aware of any filesystem size limits that small.
Thinking about the tests, the reason I started monitoring after the copy from urandom was that that operation was pretty slow regardless where it was run (urandom generally blocks until it gets enough entropy etc etc) so I didn't include it in my calculations.
Perhaps sticking in periodic "sync"s will help.... or I guess I could remount the sdcard as synchronous and hope that mountd doesn't get arsey
I'll have another look tonight
i got this is it good?
sdcard results
Code:
# time dd if=/dev/urandom of=/data/random.bin bs=1 count=1024000
time dd if=/dev/urandom of=/data/random.bin bs=1 count=1024000
1024000+0 records in
1024000+0 records out
real 0m 47.49s
user 0m 3.52s
sys 0m 42.91s
/data/ results
Code:
# time dd if=/dev/urandom of=/data/random.bin bs=1 count=1024000
time dd if=/dev/urandom of=/data/random.bin bs=1 count=1024000
1024000+0 records in
1024000+0 records out
real 0m 46.87s
user 0m 4.08s
sys 0m 41.36s
/dev/urandom is a bad way of measuring sd card speed since urandom makes intensive use of cpu and results will vary depending on processor speed / processor load etc.
in case, use dd if=/dev/zero which is less processor ungry
unrafa said:
/dev/urandom is a bad way of measuring sd card speed since urandom makes intensive use of cpu and results will vary depending on processor speed / processor load etc.
in case, use dd if=/dev/zero which is less processor ungry
Click to expand...
Click to collapse
big difference i just ran it on the sdcard can got this
Code:
# time dd if=/dev/zero of=/data/random.bin bs=1 count=1024000
1024000+0 records in
1024000+0 records out
real 0m 19.75s
user 0m 3.11s
sys 0m 15.82s
unrafa said:
/dev/urandom is a bad way of measuring sd card speed since urandom makes intensive use of cpu and results will vary depending on processor speed / processor load etc.
in case, use dd if=/dev/zero which is less processor ungry
Click to expand...
Click to collapse
Thanks for that information! I was under the misconception that the ARM CPU could put out numbers faster than could be written to SD.
Rerunning the test now...
Code:
# time dd if=/dev/zero of=/data/random.bin bs=1 count=1024000
1024000+0 records in
1024000+0 records out
real 0m 23.62s
user 0m 3.47s
sys 0m 15.78s
# time dd if=/dev/zero of=/sdcard/random.bin bs=1 count=1024000
1024000+0 records in
1024000+0 records out
real 0m 21.80s
user 0m 3.59s
sys 0m 17.89s
#
So, even on my Class 2 card, writing /data is about as fast as writing /sdcard. That's good news for further experimenation.
I also tried reading from the device in blocks of one byte and writing; turns out reading takes about a third of the time. Again, internal and external (SD) NAND are the same speed at class 2.
Code:
# time dd if=/data/random.bin of=/data/random2.bin bs=1 count=1024000
1024000+0 records in
1024000+0 records out
real 0m 33.15s
user 0m 2.65s
sys 0m 24.47s
# time dd if=/sdcard/random.bin of=/sdcard/random2.bin bs=1 count=1024000
1024000+0 records in
1024000+0 records out
real 0m 34.38s
user 0m 2.99s
sys 0m 29.03s
#
this is from a class 2?
Code:
# time dd if=/dev/zero of=/data/random.bin bs=1 count=1024000
1024000+0 records in
1024000+0 records out
real 0m 23.62s
user 0m 3.47s
sys 0m 15.78s
# time dd if=/dev/zero of=/sdcard/random.bin bs=1 count=1024000
1024000+0 records in
1024000+0 records out
real 0m 21.80s
user 0m 3.59s
sys 0m 17.89s
#
not much difference from my class 6 A-Data :/
Nitro212 said:
this is from a class 2?
not much difference from my class 6 A-Data :/
Click to expand...
Click to collapse
Yea, these are my results. I use a SanDisk 16GB Class 2. Would you post your exact results as well? I'm interested in what "not much difference" means. Maybe your card is faster at reading?
Right I made some alterations to my test.
First I tried peppering the copies with "sync" to minimise the effects of caching. But eventually I just gave up and remounted my sdcard with the "sync" option, and it did indeed make quite a difference. One thing to note though, I only ever time the actual copy, I only ready from (in my case urandom) a device before timing, the reason I used urandom is that I just wanted to be absolutely sure that the file in question has high entropy. The reason I don't time reading from /dev/zero is that tests writing and "data-creation from a specific block device" not reading and writing.
So here are my results for a similar 1024000 byte file:
Code:
/sdcard/tmp # ash disktst3.sh
ash disktst3.sh
1+0 records in
1+0 records out
real 0m 7.52s
user 0m 0.00s
sys 0m 0.35s
/data # ash disktst3.sh
ash disktst3.sh
1+0 records in
1+0 records out
real 0m 0.66s
user 0m 0.00s
sys 0m 0.08s
more disktst3.sh
dd if=/dev/urandom of=tst0.bin bs=1024000 count=1
time cp tst0.bin tst1.bin
rm tst0.bin
rm tst1.bin
Looks like my previous results reversed, but I just want to make sure that scales as expected.
Code:
/sdcard/tmp # ash disktst3.sh
ash disktst3.sh
1+0 records in
1+0 records out
real 0m 31.10s
user 0m 0.01s
sys 0m 1.92s
/data # ash disktst3.sh
ash disktst3.sh
1+0 records in
1+0 records out
real 0m 8.47s
user 0m 0.01s
sys 0m 1.38s
/data # more disktst3.sh
more disktst3.sh
dd if=/dev/urandom of=tst0.bin bs=1024000 count=1
time ash disktst2.sh
rm tst9.bin
/data # more disktst2.sh
more disktst2.sh
cp tst0.bin tst1.bin
rm tst0.bin
cp tst1.bin tst2.bin
rm tst1.bin
cp tst2.bin tst3.bin
rm tst2.bin
cp tst3.bin tst4.bin
rm tst3.bin
cp tst4.bin tst5.bin
rm tst4.bin
cp tst5.bin tst6.bin
rm tst5.bin
cp tst6.bin tst7.bin
rm tst6.bin
cp tst7.bin tst8.bin
rm tst7.bin
cp tst8.bin tst9.bin
rm tst8.bin
Just to be sure that there is no caching on data (just a different type of caching) I remounted /data with "-o sync"
Code:
/data # mount
mount
rootfs on / type rootfs (ro)
tmpfs on /dev type tmpfs (rw,mode=755)
devpts on /dev/pts type devpts (rw,mode=600)
proc on /proc type proc (rw)
sysfs on /sys type sysfs (rw)
tmpfs on /sqlite_stmt_journals type tmpfs (rw,size=4096k)
/dev/block/mtdblock3 on /system type yaffs2 (ro)
/dev/block/loop0 on /system/modules type cramfs (ro)
/dev/block/loop1 on /system/xbin type cramfs (ro)
/dev/block/mtdblock5 on /data type yaffs2 (rw,nosuid,nodev)
/dev/block/mtdblock4 on /cache type yaffs2 (rw,nosuid,nodev)
/dev/block/mmcblk0p1 on /sdcard type vfat (rw,sync,fmask=0000,dmask=0000,codepage=cp437,iocharset=iso8859-1)
/data # mount -o remount,rw,nosuid,nodev,sync -t yaffs2 /dev/block/mtdblock5 /data
mount -o remount,rw,nosuid,nodev,sync -t yaffs2 /dev/block/mtdblock5 /data
/data # mount
mount
rootfs on / type rootfs (ro)
tmpfs on /dev type tmpfs (rw,mode=755)
devpts on /dev/pts type devpts (rw,mode=600)
proc on /proc type proc (rw)
sysfs on /sys type sysfs (rw)
tmpfs on /sqlite_stmt_journals type tmpfs (rw,size=4096k)
/dev/block/mtdblock3 on /system type yaffs2 (ro)
/dev/block/loop0 on /system/modules type cramfs (ro)
/dev/block/loop1 on /system/xbin type cramfs (ro)
/dev/block/mtdblock5 on /data type yaffs2 (rw,sync,nosuid,nodev)
/dev/block/mtdblock4 on /cache type yaffs2 (rw,nosuid,nodev)
/dev/block/mmcblk0p1 on /sdcard type vfat (rw,sync,fmask=0000,dmask=0000,codepage=cp437,iocharset=iso8859-1)
/data # ash disktst3.sh
ash disktst3.sh
1+0 records in
1+0 records out
real 0m 8.97s
user 0m 0.01s
sys 0m 1.37s
Yep very similar, well thats more expected. So in real circumstances the nand flash storage seems to be about 16 Mb/s (Megabits/sec) (9 reads 9 writes of 1024000 bytes)
And my class2 card is about 4.7 Mb/s which seems like a more realistic number for a min 2Mb/sec card.
Oh hang on... are they measuring throughput in MB/sec... odd, bandwidth is generally in bits and si multipliers ok that would be ~0.5 MiB/s
Either way it's an quarter of the speed of the nand flash. Even if we managed to get class 6 16GB cards (assuming the G1 sd interface supports the speed) that would still be approx 3/4 of the speed of the nand flash.
Hmmm, I wonder if the ext partitions that people are making for their apps are mounted with "-o sync", could be important.
Related
i keep getting error failed to install insufficient space.. sd storage available 58 mb...
after i installed that steam window app soon after 3 of my apps dissapeared and now im getting that wtf
# busybox df -h
busybox df -h
Filesystem Size Used Available Use% Mounted on
tmpfs 48.4M 0 48.4M 0% /dev
tmpfs 4.0M 0 4.0M 0% /sqlite_stmt_journals
/dev/block/mtdblock3 67.5M 64.0M 3.5M 95% /system
/dev/block/loop0 1.5M 1.5M 0 100% /system/modules
/dev/block/loop1 3.1M 3.1M 0 100% /system/xbin
/dev/mmcblk0p2 1.5G 14.4M 1.5G 1% /system/sd
/dev/block/mtdblock5 74.8M 17.4M 57.3M 23% /data
/dev/block/mtdblock4 67.5M 1.2M 66.3M 2% /cache
/dev/block/mmcblk0p1 5.8G 876.5M 5.0G 15% /sdcard
i moved my data/data to sd and still says that.. anyeone someone please help.. i did that by diong this command..
adb shell
cp -a /data/data /system/sd
rm -r /data/data
ln -s /system/sd/data /data/data
you try a wipe? that seems to fix all of my problems
haitiankid4lyf said:
you try a wipe? that seems to fix all of my problems
Click to expand...
Click to collapse
wipe didnt work.. i re did root process .. again!... installed adp1.1 but i think ill go back to rc 30 soon.. some apps are not compatible.. like droid auto rotate.. and some other ones.. self help is messy same as toggle gps
Smokuevo said:
i moved my data/data to sd and still says that.. anyeone someone please help.. i did that by diong this command..
adb shell
cp -a /data/data /system/sd
rm -r /data/data
ln -s /system/sd/data /data/data
Click to expand...
Click to collapse
If you are trying to copy to the SD card shouldn't you use:
cp -a /data/data /sdcard/[whatever subfolder]
foxtrickle said:
If you are trying to copy to the SD card shouldn't you use:
cp -a /data/data /sdcard/[whatever subfolder]
Click to expand...
Click to collapse
sd is ext2 part sdcard is fat32....!..
after i installed JF V1.41 i could no longer do move data to sd.
Code:
adb shell
cp -a /data/data /system/sd
rm -r /data/data
ln -s /system/sd/data /data/data
after I did that, I would have to do wipe and I beleive that superuser would give the error 3 or something.
I did the app to sd instead of data and linked cache to sd and working like a charm.
i know theres a thread but i'm confuse about what to install and run to transfer my apps to my sd card.
my sd card is already partitioned to 6gb fat32 and 2gb ext2 and its rooted with jf1.41 as well.
please give me a specific instructions cuz im a noob when it comes to adb shell sdk cmd or whatever computer words.
thanks in advance!
Well i'm a noob as well can't seam to finish the last step myself but i'll try my best.
Just a wild gues u r running Windows right?
yeah im using windows xp but it has vista transformation pack if that will make a difference.
Ok.
Have u got "modified mountd & init.zip (685 Bytes, 475 views)" wich is an attachement at the bottom of http://forum.xda-developers.com/showthread.php?t=468959 ???
Download this small zip from http://modmygphone.com/wiki/index.php/Setting_up_ADB . Unzip the files to a desktop and copy it to system folder after that follow this link http://www.computerhope.com/issues/ch000549.htm.
let me know when u r done???
But remember i am also a big time noob but just trying to help as much as i can when no one else will so if i get some thing wrong don't get angry with me just let me know what i told u that was wrong and that way we can help each other out and correct one n other.
Zionator said:
But remember i am also a big time noob but just trying to help as much as i can when no one else will so if i get some thing wrong don't get angry with me just let me know what i told u that was wrong and that way we can help each other out and correct one n other.
Click to expand...
Click to collapse
if you copy the modified mount.conf and init.rc files to the SD card at the root then this would be the way in "Terminal":
$su
#busybox cp -a /sdcard/mount.conf /system/etc/mount.conf
#busybox cp -a /sdcard/init.rc /system/init.rc
#mkdir /system/sd
now that the modified files are there you MUST reboot .. this is all done after you have root and after you have done the double partitions on your SD card .. once you reboot you should go back to the "Terminal" to make sure everything's good
$su
#busybox df -h
if you don't see a line like this:
/dev/mmcblk0p2 1.5G 94.4M 1.3G 7% /system/sd
then something didn't mount properly .. so if you DO see this line now you can continue:
#busybox cp -a /data/app /system/sd
#rm -r /data/app
#ln -s /system/sd/app /data/app
#busybox cp -a /data/app-private /system/sd
#rm -r /data/app-private
#ln -s /system/sd/app-private /data/app-private
now the apps are all on the EXT2 partition of the MicroSD .. happy downloading
I don't know what i have done wrong but eveything i try i keep getting errors and u have been more then help full but i am proberly to stupid to do it my self and i know i can do it if only i could find a video toturial from youtube or so but can't find any so i am stuck here.
But thank you very much for all ur help i would never have gotten to the last step with out ur help.
So now my only option is a help video or remote pc help if that is possible.
Ps. xda should make u a Moderator or Admin cause u r very help full and u know what u r talking about.
Zionator said:
I don't know what i have done wrong but eveything i try i keep getting errors and u have been more then help full but i am proberly to stupid to do it my self and i know i can do it if only i could find a video toturial from youtube or so but can't find any so i am stuck here.
But thank you very much for all ur help i would never have gotten to the last step with out ur help.
So now my only option is a help video or remote pc help if that is possible.
Ps. xda should make u a Moderator or Admin cause u r very help full and u know what u r talking about.
Click to expand...
Click to collapse
it's a nice thought .. not really sure i'd want to hold that kind of responsibility tho .. i think it'd be like calling me "Mr. President" when i drive the local garbage truck .. these guys are doing great here .. i'm just glad to lend a hand and hope it helps out
Hey guys just thought i'd chime in.
Firstly just to clarify are you using adb from your windows system or are you trying to do this all on the terminal app because these commands are issued to terminal after replacing both mount.conf and init.rc as described above
$su
#busybox df -h
as above you should see a line "/dev/SOMETHING" "size data" "/system/sd"
if you don't see this line then there's most likely a problem with your card format, did you make sure you had fat32 first then ext2 in that order on the card, fat32 must be first. i find it helps to check if camera can use the sdcard, if it can't, reformat, unmount and check camera again.
Assuming you've gotten this right so far
#busybox cp -a /data/app /system/sd
#rm -r /data/app
#ln -s /system/sd/app /data/app
#busybox cp -a /data/app-private /system/sd
#rm -r /data/app-private
#ln -s /system/sd/app-private /data/app-private
and hopefully your apps should all work, but not appear as downloaded in the market (don't worry this'll change if you reinstall them from the market)
if you're using adb from windows to try the above the commands will be slightly different:
Procedure:
***********************************************************
- this can be skipped if you've already replaced the mountd.conf and init.rc
adb remount
adb shell mkdir /system/sd
adb shell ls /system
adb push LOCATION OF FILE/mountd.conf system/etc/mountd.conf
adb push LOCATION OF FILE/init.rc system/init.rc
(LOCATION OF FILE = the folder you have the modified files)
adb shell
reboot
***********************************************************
If you've skipped ahead
adb remount
adb shell
busybox df -h
as above you should see a line "/dev/SOMETHING" "size data" "/system/sd"
Again if this line doesn't exist you've missed something, go back
busybox cp -a /data/app/ /system/sd
rm -r /data/app/
ln -s /system/sd/app /data/app
busybox cp -a /data/app-private /system/sd/app-private
rm -r /data/app-private
ln -s /system/sd/app-private /data/app-private
reboot
and hopefully your apps will all work and again, not appear in market.
If this doesn't help please advise what error messages you are getting and exactly where everythings going wrong, maybe we can get you back on track.
just reformated the card from fat 16 to fat 32 as u said hope it works now lol.
And thanks for the help.
Keep u posted.
C:\Users\Illuminator\Desktop>adb shell
# busybox df -h
busybox df -h
Filesystem Size Used Available Use% Mounted on
tmpfs 48.4M 0 48.4M 0% /dev
tmpfs 4.0M 0 4.0M 0% /sqlite_stmt_journals
/dev/block/mtdblock3 67.5M 67.5M 0 100% /system
/dev/block/loop0 1.4M 1.4M 0 100% /system/modules
/dev/block/loop1 3.1M 3.1M 0 100% /system/xbin
/dev/block/mtdblock5 74.8M 44.6M 30.1M 60% /data
/dev/block/mtdblock4 67.5M 1.3M 66.2M 2% /cache
/dev/block/mmcblk0p1 1.3G 4.0K 1.3G 0% /sdcard
#
--------------------------------------------------------------
# busybox cp -a /data/app/ /system/sd
busybox cp -a /data/app/ /system/sd
cp: write error: No space left on device
cp: write error: No space left on device
cp: write error: No space left on device
The list goes on and on. puha need a smoke.
But thanks for help.
why does it say "No space left on device"???
C:\Users\Illuminator\Desktop\G2>adb push C:\Users\Illuminator\Desktop\G2\/mountd
.conf /system/etc/mountd.conf
failed to copy 'C:\Users\Illuminator\Desktop\G2\/mountd.conf' to '/system/etc/mo
untd.conf': No space left on device
Ok might be fine but better safe than sorry your last line says:
/dev/block/mmcblk0p1 1.3G 4.0K 1.3G 0% /sdcard
That means that you're sdcard in fat32 format is only 1.3gbs in size is that correct? I assume this means you're using the sdcard that came free with the phone (2gb) if your card is larger say an 4 or an 8 something has gone wrong, but if this is correct lets move on.
cool so your sdcard is now partitioned fat32 -1.3gb followed by 0.7gb ext2
better safe than sorry redownload http://forum.xda-developers.com/attachment.php?attachmentid=139735&d=1230107855 the files and place them (the 2 files, not the folder) in the same folder as adb (do not mount your usb card)
>adb remount
>adb push mountd.conf system/etc/mountd.conf
>adb push init.rc system/init.rc
>adb shell
#mkdir /system/sd
#ls /system
(make sure a folder called sd exist)
#reboot
When your android reboots
>adb remount
>adb shell
#busybox df -h
Cross fingers, pray, beg, bargain and look for the line
"/dev/SOMETHING" "size data" "/system/sd"
in case this doesn't work i'm going to pm you my email, we can chat on google messenger and try and get this sorted
Quick question are you remembering to "adb remount" when you attach the phone - if you don't the phone wont be writable, which may explain the no space issue here:
C:\Users\Illuminator\Desktop\G2>adb push C:\Users\Illuminator\Desktop\G2\/mountd
.conf /system/etc/mountd.conf
failed to copy 'C:\Users\Illuminator\Desktop\G2\/mountd.conf' to '/system/etc/mo
untd.conf': No space left on device
*********but here you are trying to write to a location that doesn't exist, unless you see the magic line ending system/sd you cannot proceed
# busybox cp -a /data/app/ /system/sd
busybox cp -a /data/app/ /system/sd
cp: write error: No space left on device
cp: write error: No space left on device
Jesus this is killing me!!! yesterday i got all the way to step.12
And yes the sd came with the phone sdcard in fat32 -1.3gb followed by 0.7gb ext2 - yes that's correct.
And in case u where woundering then yes my phone is rooted wich was a pice of pie compered to this lol.
---------------------------------------------------------------------
C:\Users\Illuminator\Desktop>adb remount
remount succeeded
C:\Users\Illuminator\Desktop>adb push mountd.conf system/etc/mountd.conf
failed to copy 'mountd.conf' to 'system/etc/mountd.conf': No space left on devic
e
C:\Users\Illuminator\Desktop>adb push C:\Users\Illuminator\Desktop\/mountd.conf
system/etc/mountd.conf
failed to copy 'C:\Users\Illuminator\Desktop\/mountd.conf' to 'system/etc/mountd
.conf': No space left on device
C:\Users\Illuminator\Desktop>
You're not kidding i've done this 5 times (on 3 phones - updates) never had this much trouble!
do you have the same problems if you sit the files on your sdcard and do the following? if so as much as it sucks to lose your data i would strongly suggest doing a wipe before hand (reboot phone holding home and at prompt alt + w)
>adb shell
#busybox cp -a /sdcard/mount.conf /system/etc/mount.conf
#busybox cp -a /sdcard/init.rc /system/init.rc
#mkdir /system/sd
C:\Users\Illuminator\Desktop>adb shell mkdir /system/sd
mkdir failed for /system/sd, File exists
fantastic, well that's something! how about the other two did both copy successfully? and if so does the magic line appear after reboot?
faithnolonger said:
fantastic, well that's something! how about the other two did both copy successfully? and if so does the magic line appear after reboot?
Click to expand...
Click to collapse
Just restarting the phone but for some reason all the app are copyed to the fat32 part of the sdcard lol.
oh no for some odd reason the sdcard is not working no more???
--------------------------------------------------------------------
# busybox df -h
busybox df -h
Filesystem Size Used Available Use% Mounted on
tmpfs 48.4M 0 48.4M 0% /dev
tmpfs 4.0M 0 4.0M 0% /sqlite_stmt_journals
/dev/block/mtdblock3 67.5M 67.5M 0 100% /system
/dev/block/loop0 1.4M 1.4M 0 100% /system/modules
/dev/block/loop1 3.1M 3.1M 0 100% /system/xbin
/dev/block/mtdblock5 74.8M 44.6M 30.1M 60% /data
/dev/block/mtdblock4 67.5M 1.3M 66.2M 2% /cache
#
------------------------------------------------------------------------
Just wiped the system on the phone and reinstalling the JFv1.31
wow that's not right your apps should not be there:S
ok maybe time to go to real time chat i've got my android next to me, i've pm'd you my email address, you can message me over IM
Ok thanks i am ready in chat mode hehe.
when i type any of the adb command stuff i keep getting error: device not found. i don't know what to do next.
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.
free
total used free shared buffers
Mem: 183584 176468 7116 0 8
-/+ buffers: 176460 7124
Swap: 0 0 0
df
Filesystem 1K-blocks Used Available Use% Mounted on
tmpfs 91792 12 91780 0% /dev
tmpfs 4096 0 4096 0% /sqlite_stmt_journals
/dev/block/mtdblock4 174080 155676 18404 89% /system
/dev/block/mtdblock6 194176 69136 125040 36% /data
/dev/block/mtdblock5 71680 1172 70508 2% /cache
/dev/block/mtdblock7 20480 1168 19312 6% /data/HWUserData
/dev/block//vold/179:1
1919304 6320 1912984 0% /sdcard
so can i enable a swap partition to my android device? how to make it?
Use home partition wizard tool
Hope can help you
RudzLong said:
Use home partition wizard tool
Hope can help you
Click to expand...
Click to collapse
so can i create partition using fdisk directly?
the issue is whether the kernel support swap function, agree with that?
bigmeow said:
so can i create partition using fdisk directly?
the issue is whether the kernel support swap function, agree with that?
Click to expand...
Click to collapse
Yes, the kernel supports swapping. But Android do not page swap by design, but kills of entire processes instead. I.e. the "swapping" (memory management) is implemented at application level. Swapping is slow, you'll get at best 20MB/s disk I/O, and Android must be "real time best effort". E.g. if your are playing Angry Birds and have your phone app out-paged, it'll take time to page it back in again, before you can answer your friend calling. It's much quicker to kill of the Angry Bird than have to page it out, especially as the I/O capacity is occupied loading the phone app.
But yes, you can enable paging on the Android device, and it'll probably work quite fine most of the times. But ApplicationManager doesn't really cares, it'll kill of your apps anyway. Running native code although, it'll give you some gain.
kuisma said:
Yes, the kernel supports swapping. But Android do not page swap by design, but kills of entire processes instead. I.e. the "swapping" (memory management) is implemented at application level. Swapping is slow, you'll get at best 20MB/s disk I/O, and Android must be "real time best effort". E.g. if your are playing Angry Birds and have your phone app out-paged, it'll take time to page it back in again, before you can answer your friend calling. It's much quicker to kill of the Angry Bird than have to page it out, especially as the I/O capacity is occupied loading the phone app.
But yes, you can enable paging on the Android device, and it'll probably work quite fine most of the times. But ApplicationManager doesn't really cares, it'll kill of your apps anyway. Running native code although, it'll give you some gain.
Click to expand...
Click to collapse
the issue is how to enable paging?
bigmeow said:
the issue is how to enable paging?
Click to expand...
Click to collapse
Code:
[email protected]:/usr/tmp # free
total used free shared buffers
Mem: 738260 723056 15204 0 78588
-/+ buffers: 644468 93792
Swap: 0 0 0
[email protected]:/usr/tmp # busybox dd bs=1M if=/dev/zero of=swapfile count=256
256+0 records in
256+0 records out
268435456 bytes (256.0MB) copied, 20.161636 seconds, 12.7MB/s
[email protected]:/usr/tmp # busybox mkswap /usr/tmp/swapfile
Setting up swapspace version 1, size = 268431360 bytes
UUID=35fb0d4e-b0ed-4b08-9935-64b85e71d6ce
[email protected]:/usr/tmp # busybox swapon /usr/tmp/swapfile
[email protected]:/usr/tmp # free
total used free shared buffers
Mem: 738260 650516 87744 0 78824
-/+ buffers: 571692 166568
Swap: 262140 0 262140
Change "count=256" to the size (in MB) you want your the swap. Locate the file to your fastest disk, here I'm using /usr/tmp, but I guess you'll have to place it somewhere else, since /usr/tmp usually don't exists in Android. You'll have to use either /data (expensive!) or make a new ext3 partition on your SD card for this (best, if you've got a fast SD card). The swap file can reside on the sdcard, but it must not be on the fat partition, but on an ext3 or ext4 partition.
Unfortunately kernel doesn't allow for that
(Galaxy Note, SpeedMod kernel k-11)
Code:
/sdcard $ dd if=/dev/zero of=swapfile bs=1M count=256
256+0 records in
256+0 records out
268435456 bytes (256.0MB) copied, 31.747960 seconds, 8.1MB/s
/sdcard $ busybox mkswap swapfile
Setting up swapspace version 1, size = 268431360 bytes
/sdcard $ busybox swapon swapfile
swapon: swapfile: Function not implemented
/sdcard $
/sdcard $
Carefully crafted on my Galaxy Note, for your eyes only
debernardis said:
Code:
/sdcard $ busybox swapon swapfile
swapon: swapfile: Function not implemented
Click to expand...
Click to collapse
Try swapping on an ext3/ext4 device, and also use the full file path of the swap file to "busybox swapon".
Edit: Tested. If I try swapping on a FAT disk, I'll get the same error. ext3/4 works like a charm.
kuisma said:
Try swapping on an ext3/ext4 device, and also use the full file path of the swap file to "busybox swapon".
Edit: Tested. If I try swapping on a FAT disk, I'll get the same error. ext3/4 works like a charm.
Click to expand...
Click to collapse
hey dev i read the whole thread n came to the conclusion that my device which is unbranded doesnt have swap support in kernel nor ext3-4 support
i tried swapper 2 with swap file but it shows function not implemented
so i tried to mount ext3 partition but it doesnt mount on the device seems it dont have ext3 support whereas i tried ext2 n mounted successfully but swap file on it still shows function not implemented
it would b nice if u can help me
thanks alot
Hi Guys,
I have an Blu Dash 3.5 D170, but i do not have a system android yet... i've got a little problem:
I'm trying to install a backup system.img I got here, but always fails in writing step because the lack of space in /system
when i use adb shell ls -a /system the result is:
Code:
D:\Android\sdk\platform-tools>adb shell
~ # ls -a /system
ls -a /system
. .. lost+found
~ #
other words, there is nothing inside /system...
When i use "busybox df", results is:
Code:
~ # busybox df
busybox df
Filesystem 1K-blocks Used Available Use% Mounted on
tmpfs 80612 48 80564 0% /dev
/dev/block/mtdblock1 225280 148096 77184 66% /system
/dev/block/mtdblock4 179200 1216 177984 1% /data
/dev/block/mmcblk0p1 3850240 118624 3731616 3% /sdcard
/dev/block/mtdblock2 61440 1192 60248 2% /cache
~ #
I can not understand why occupies 66% of the space is has NOTHING within the directory
I tried using the command "fastboot erase system", and the command says that cleared the system, but it does not clear these 66%
what should I do to fix this?