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.
Related
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.
Please someone more experienced than me check the prosedure!!! Till I remove this line go with extreme caution
I have an enormous amount of applications inherited from the partition-able optimus 2x. I got optimus 3D as an upgrade but I couldn’t intall not even half of them. So I was trying to find ways to repartition /data as I had done with optimus 2x but with no success.
Then I got an idea... why not A2SD style? So it begins
Disclaimer: Have in mind that I’ve done nasty stuff which could brick the phone badly. I take no responsibility for breaking your phone even if you follow my guide perfectly. I am no developer and I can make mistakes so please don’t continue if you don’t understand what I am telling you to do. Also be careful since I dont know how future lg updates will react
My composition is: Thiaiz Rom V0.1, clockworkmod touch, rooted ofc and I have installed most drivers found on this forum for o3d.
Before you begin get a backup of your internal memory, sd card, titanium backup and nand backup to a pc. You WILL loose internal memory data. The rest just to be safe....
Drawbacks: Your internal memory will be around 2-3gbs smaller and wont be able to be mounted to the pc. You could brick your phone.
While all these can be done with a cwm zip script I did it manually. Also since my phone works fine know and my time is short I dont really want to go to the reformating coping restoring backups again. This means that while I write this guide I dont actually run these command only checking them if they are correct.
Lets start.
First shutdown your phone. Open it to recovery by pressing down button and power for 7-8 seconds. Release when you see LG logo. While in recovery connect your device with the pc with a usb cable. Open command prompt on your windows pc and do a
adb shell
Now you are probably ready to send commands. If not use a guide like this http://www.addictivetips.com/mobile/what-is-adb-and-how-to-install-it-android/
at the shell do a
Code:
# cd /dev/block
#ls
you will see all your partitions. mmcblk0 is the internal memory and mmcblk1 is the sd card.
Code:
# parted mmcblk0
(parted) print
now you see the partitions
You should see something like this
Code:
Number Start End Size File system Name Flags
1 131kB 262kB 131kB x-loader
2 262kB 393kB 131kB nv1
3 393kB 524kB 131kB nv2
4 524kB 1049kB 524kB u-boot
5 1049kB 11.5MB 10.5MB kernel
6 11.5MB 22.0MB 10.5MB recovery
7 22.0MB 651MB 629MB ext3 system
8 651MB 1725MB 1074MB ext3 userdata
9 1725MB 1859MB 134MB fsswap
10 1859MB 1926MB 67.1MB ext3 cache
11 1926MB 1928MB 2097kB ext3 lgdrm
12 1928MB 1929MB 1049kB divxkey
13 1929MB 1950MB 21.0MB fota
14 1950MB 1955MB 4194kB ext3 misc
15 1955MB 7944MB 5989MB fat32 msftres
we are going to work on partition 15 starting by deleting it. Be very carefull here what you delete
Code:
(parted) rm 15
now we want to create 2 more partitions. The 1955-4944 and 4944-7944 will give you around 3gb for apps and 3gb for internal memory. Tweak it at your needs but always follow the numbers. I meant if your print gave you this output
Code:
15 1955MB 7945MB 2989MB fat32
use 7945 and not 7944
Code:
(parted) mkpartfs primary fat32 1955 4944
(parted) mkpartfs primary ext2 4944 7944
now the command print should give you two more partitions
Code:
15 1955MB 4944MB 2989MB fat32 msftres
16 4944MB 7944MB 3000MB ext2
quit parted to update the ext2 to ext3
Code:
(parted) quit
#mke2fs /dev/block/mmcblk0p16
#tune2fs -j /dev/block/mmcblk0p16
Now our phone is ready for A2SD. Reboot the phone.
After finish rebooting continue via adb or terminal (I used terminal because I was in a 3 hours trip with bus ) and es file explorer with root and rw options on
we need to tweak /etc/vold.fstab to change the mount points. You can change it with es file explorer
My file is:
Code:
dev_mount sdcard /mnt/sdcard auto /devices/platform/mmci-omap-hs.0/mmc_host/mmc1
dev_mount extsdcard /mnt/sdcard/_ExternalSD 15 /devices/platform/mmci-omap-hs.1/mmc_host/mmc0
then we need to create the mount point for our new partition. I did it at /mnt/a2sd but you can do it anyware including the standard /system/sd
Code:
#mkdir /mnt/a2sd
#mkdir /mnt/emmc
now we need to mout our new partition everytime the system starts. I opened /etc/init.d/thiaizSDbooster and added few lines
Code:
mkdir /mnt/a2sd
mount -w /dev/block/mmcblk0p16 /mnt/a2sd
mkdir /mnt/emmc
mount -w /dev/block/mmcblk0p15 /mnt/emmc
ln -s /mnt/a2sd/data/app /data/app
ln -s /mnt/a2sd/data/data /data/data
dont forget to make the correct permitions again after the edit
now you need to mount the new partition to your mount point
Code:
#mount -w /dev/block/mmcblk0p16 /mnt/a2sd
and copy the data files you will link there
Code:
#cp -a /data /mnt/a2sd
now careful youll delete the /data/app and /data/data from /data
Code:
#rm -r /data/app
#rm -r /data/data
and create the links
Code:
#ln -s /mnt/a2sd/data/app /data/app
#ln -s /mnt/a2sd/data/data /data/data
Reboot the phone and you are ready to go!
To mount the sd card to the pc you will need an app from market https://market.android.com/details?id=com.rafoid.multimountsdcard.widget.free
Look atached images for what you get
want to give it a try but I need to know if there is a way to revert back if anything goes wrong. Will a restore of a previous backup return things to normal?or flashing a kdz? thanx anyway.any try to improve our phones is worth praize...
jimakos29 said:
want to give it a try but I need to know if there is a way to revert back if anything goes wrong. Will a restore of a previous backup return things to normal?or flashing a kdz? thanx anyway.any try to improve our phones is worth praize...
Click to expand...
Click to collapse
Make a nand back-up in another sd card, if you re lucky and can still boot upto recovery then you can restore or you can boot to download mode. Last resort will be to flash a bin or kdz file then restore your nand back up.
I bricked my phone 5 times in one month 2 times in 1 day. I still figured how to restore, just relax and think before you do crazy stuff, all the answers are in XDA.
---------- Post added at 04:44 AM ---------- Previous post was at 03:49 AM ----------
@orlox tested it and gives me phone memory damage, forgot to pull the logs and do some ss, well anyways I won't be doing this one, I was setting up for the s2e and link2sd stuff -- that one is not that risky.
mtvtitan said:
tested it and gives me phone memory damage, forgot to pull the logs and do some ss, well anyways I won't be doing this one, I was setting up for the s2e and link2sd stuff -- that one is not that risky.
Click to expand...
Click to collapse
The "damage part" is because you probably didnt change the vold file. Its not something to worry. After you tell vold what partition to mount (15) it will be ok
orlox said:
The "damage part" is because you probably didnt change the vold file. Its not something to worry. After you tell vold what partition to mount (15) it will be ok
Click to expand...
Click to collapse
I figured that one...
have you finished the guide? all ok?
orlox said:
have you finished the guide? all ok?
Click to expand...
Click to collapse
not yet, got other stuff in hand... i'll try to report tom* its already 2am here and have work at 4am -- cooked.
I made a mistake somewhere and am stuck. Can't sleep now, I'll have to figure this thing thorough.
---------- Post added at 07:20 AM ---------- Previous post was at 07:12 AM ----------
btw you can try this --> install link2sd let it install the script needed to mount 2nd sd part, then edit it (init.d folder)
--> add this before mounting sdext2
sleep 2
mkdir /sd-ext
sleep 2
--> then after mounting sdext2 insert this
sleep 2
mount -o bind /data/sdext2 /sd-ext
-----------------------------------------
install s2e
move dl cache (dont move any apps, let link2sd do that)
reboot.
----------------------------------------------
works with thiaz boot image only
the risk is low and would not probably brick your phone but try it at your own risk (disclaimer) --> this is generic, do your mods.
any problems will discuss after I unbrick my phone lol.
Generic scripts are not working well. I was trying with dark tremors first. I think manual is safer. Also Someone may want to partition sd instead of nand. Its safer but I think its a waste of space.
The good thing is that parted works so we don't need a tool like nvflash. Also /data had a limit at 2GB I think. With a2sd there is no limit.
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
Note: This is probably only helpful for people with a computer science or linux hacking background!
We all know the single biggest issue with this phone is the lack of internal memory for apps and app data. The internal partitioning looks like this:
/system 1 GB
/data 2 GB
sdcard0 4 GB -- lots of space that competes with external SD! Let's use it!
other stuff (tmp, boot, etc.) 1 GB
persona78 provided an excellent mod of the (most recent) stock ROM that gives you root and a working init.d:
https://forum.xda-developers.com/ascend-g6/general/root-upadtekinguser-zip-modded-extras-t3349679
This mod also enables to move apps to a new ext4 partition on the external SD card. My experience however is:
dalvik cache and app data (e.g. some social media apps caching videos etc.) will still fill up the /data partition
access to external SD, even a fast one, is much slower
if you also move app data to external SD, the phone becomes unusable (slow)
So I propose the following solution, successfully tested on my phone, that will use just short of 6 GB on the internal SD card for dalvik cache, apps and their data!
This is how to do it:
backup everything important from the phone
unlock bootloader and install the ROM from persona78, linked above. Make sure root works, adb works.
connect to a Linux machine via USB that has adb installed
select mass storage mode on the phone in the USB settings
Now in mass storage mode do the following:
the phone exposes a block device without partitioning (e.g. /dev/sdb) and a block device with partitioning (e.g. /dev/sdc, /dev/sdc1). the former is the internal storage (sdcard0), the latter external storage (sdcard1).
mount /dev/sdb to /mnt/internal and /dev/sdc1 to /mnt/external
rsync -a /mnt/internal/ /mnt/external/
umount /dev/sdb
mkfs.vfat -C /var/tmp/vfat 256000
dd if=/var/tmp/vfat of=/dev/sdb bs=1M (you can delete /var/tmp/vfat after this)
losetup /dev/loop0 /dev/sdb -o 262144000
mkfs.ext4 /dev/loop0
On the phone you can now change back the USB mode to MTP (but not to charge only -- a data mode is needed for adb to work).
Now run adb shell and obtain root in the shell via 'su'. In the adb root shell:
mkdir -p /data/sdext4
losetup -o 262144000 /dev/block/loop7 /dev/block/mmcblk0p25
mount -t ext4 /dev/block/loop7 /data/sdext4
in /data/sdext4, create two directories called 'data-app' and 'data-data'. Give them the respective permissions and group,ownership as with the current /data/app and /data/data directories.
cp -a /data/app/* /data/sdext4/data-app
cp -a /data/data/* /data/sdext4/data-data
rm -r /data/app/* /data/data/*
mount -o remount,rw /system
edit /etc/init.d/01AOBoot as follows
Content of /etc/init.d/01AOBoot:
#!/system/bin/sh
CONCURRENCY=makefile
# mount sdext4
losetup -o 262144000 /dev/block/loop7 /dev/block/mmcblk0p25
mount -t ext4 /dev/block/loop7 /data/sdext4
mount -o bind /data/sdext4/data-app /data/app
mount -o bind /data/sdext4/data-data /data/data
# change dalvik permissions
chmod 773 /data/dalvik-cache
# change scaling_min_freq to 300000
echo 300000 > /sys/devices/system/cpu/cpu0/cpufreq/scaling_min_freq
Click to expand...
Click to collapse
Now run adb reboot. It is done.
Explanation: Apps and their data need to reside on an ext4 partition. sdcard0 however has to be vfat, otherwise the phone will always complain and ask to format it. We can also not change the internal storage partitioning. Therefore we simply hide a large ext4 filesystem behind a small vfat filesystem on the same partition. Apps will startup fast and run fast, and all media files can be put on the external sd card.
I know this is very exotic to most, but maybe there are a few people like me with the necessary background who would like to follow my example. Happy hacking!
Are you kidding me?
This is a great work that you did. My phone keeps complaining about low disk space but I was gonna use parted to resize the data partition.
URGENT GZIP dump image of userdata problem ADB SHELL DD IF GZIP IMAGE FILE SIZES
I m using android lolipop 5.1.1 i in Qualcom smart phone was trying to root the phone i created Image file with dd command then rooted got some problems then again recovered it but when I created a fresh image file of unrooted recovered factory reset its showing different sizes for detail i am showing the commands and outputs
Created mmcblk0.img.gz through dd of /dev/block/mmcblk0 gzip
Code:
~ # ←[6n dd bs=4k conv=sync,noerror if=/dev/block/mmcblk0 | gzip -c -9 > /external_sd/mmcblk0.img.gz
PHP:
(15634268160 bytes (14.6GB) copied, 8996.230485 2 hrs 50 min seconds, 1.7MB/s)
File mmcblk0.img.gz created in external sd card formatted in ext4 showed by ls -l shows 3.68 GB size of mmcblk0.img.gz file
Code:
~ # ←[6n ls -l /external_sd/.
PHP:
-rw-rw-rw- 1 root root 3957044725 (3.685GB) Jan 5 12:32 /external_sd/mmcblk0.img.gz
where as when checked the /external_sd/ card mmcblk0.img.gz file size occupied space by df -h it showed 7.7GB occupied space
Code:
~ # ←[6n df -h
PHP:
Filesystem Size Used Available Use% Mounted on
/dev/block/mmcblk1p1 14.0G 7.7G 5.5G 58% /external_sd
Code:
~ # ←[6n df -hi
PHP:
Filesystem Inodes Used Available Use% Mounted on
/dev/block/mmcblk1p1 3.7M 12 3.7M 0% /external_sd
when i pulled mmcblk0.img.gz file to pc computer then it shows of 7.68 GB
Code:
~ # ←[6n adb pull -p /external_sd/mmcblk0.img.gz
PHP:
Copied in System 7.68 GB (8,252,012,021 bytes) file
Previously 5 days before rooting and flashing i took the same backup of mmcblk0.img.gz file with same command
Code:
adb pull -p /external_sd/mmcblk0.img.gz
PHP:
1.48 GB (1,599,262,720 bytes)
i have taken individual images also off boot.img recovery system.img and userdata.img i founded that the new images of userdata is high as well system when is less for details of user data i am giving details below
Created userdata.img.gz through dd of /dev/block/mmcblk0p29
Code:
~ # ←[6n dd bs=4k conv=sync,noerror if=/dev/block/mmcblk0p29 | gzip -c -9 > /external_sd/userdata.img.gz
PHP:
(12748570112 bytes (11.9GB) copied, 7325.311486 seconds, 2.0 hrs 1.7MB/s)
File userdata.img.gz size created in external sd card formatted in ext4 showed by ls -l shows 1.5Gb size of userdata.img.gz file
Code:
~ # ←[6n ls -l /external_sd/.
it was showing 1.5gb file
where as when checked the /external_sd/ card size of userdata.img.gz file occupied by df -h it showed 6.8 gb occupied space
/dev/block/mmcblk0p29 IS SHOWING SIZE MOUNTED IN /DATA /SDCARD OF 866.5 USED BUT ITS IMAGE IS 6.7 GB
Code:
~ # ←[6n df -h
PHP:
Filesystem Size Used Available Use% Mounted on
/dev/block/mmcblk0p29 11.6G 866.5M 10.7G 7% /data
/dev/block/mmcblk0p29 11.6G 866.5M 10.7G 7% /sdcard
/dev/block/mmcblk1p1 14.0G 6.7G 7.3G 47% /external_sd
Code:
~ # ←[6n df -hi
PHP:
Filesystem Inodes Used Available Use% Mounted on
/dev/block/mmcblk0p29 760.0K 1.9K 758.1K 0% /data
/dev/block/mmcblk0p29 760.0K 1.9K 758.1K 0% /sdcard
when i pulled userdata.img.gz file to pc computer then it shows of 6.7 GB
Code:
adb pull -p /external_sd/userdata.img.gz
PHP:
(1390 KB/s 7020532851 bytes 6.538 GB in 4929.140s 82.15 min)
userdata.img.gz file created in computer is 6.53 GB (7,020,535,808 bytes)
Previously 5 days before rooting and flashing i pulled userdata.img.gz image with same command
Code:
adb pull -p /external_sd/userdata.img.gz
PHP:
337 MB (353,608,243 bytes)
Summarized:-
DD if gzip -9 mmcblk0.img.gz compressed 15,634,268,160 bytes (14.6GB) Device data to external sd card ext4 file system
ls -l shows the file mmcblk0.img.gz size of 3,957,044,725 bytes (3.685GB) ext4 file system
Df-h shows the sd card having only one file with space occupied in external sd card with 7.77GB space
adb pull copied mmcblk0.img.gz file of 7.68 GB space (8,252,012,021 bytes)
the old image dumped file mmcblk0.img.gz of same phone and same mobile was 1.48 GB (1,599,262,720 bytes)
Founded userdata.img.gz has been enlarged
DD if gzip -9 userdata.img.gz compressed 12,748,570,112 bytes (11.9GB) Device data to external ext4 file system
ls -l shows the file userdata.img.gz size of 1.5 Gb ext4 file system
Df-h shows the sd card having only one file userdata.img.gz with space occupied in external sd card with 6.8gb space
/dev/block/mmcblk0p29 IS SHOWING SIZE MOUNTED IN /DATA /SDCARD OF 866.5M USED BUT ITS IMAGE IS 6.7 GB
adb pull copied file userdata.img.gz of 7020532851 bytes 6.538 GB
the old image dumped file userdata.img.gz of same phone and same mobile was 337 MB (353,608,243 bytes)
Now my queries kindly help and explain:-
Is there any problem with dd if gzip command syntax and options
why mmcblk0.img.gz file ls- l shows 3.685GB and df -h shows 7.7GB occupied in external_sd card and same in case of userdata.img.gz file ls -l shows 1.5gb but the occupied space as per external sd card is 6.8gb
why when the file mmcblk0.img.gz file pulled is 7.68 gb as its 7.7gb in df-h and i same in case of userdata.img.gz file pulled is 3. 6.538gb as its 6.7 Gb in df -h
why Df-h of /dev/block/mmcblk0p29 IS SHOWING SIZE MOUNTED IN /DATA /SDCARD OF 866.5M USED BUT ITS IMAGE IS made file name userdata.img.gz 6.7 GB and 1.5 Gb in ls-l
why 5 days before i flashed my rooted phone had pulled image file of mmcblk0.img.gz was 1.48 GB (1,599,262,720 bytes) and now it extended to 7.68 gb and in same way userdata.img file before was 337 MB and now its extended to 6.8gGB
Question is which file to keep and which one is ok or not mmcblk0.img.gz of 1.48 gb or 7.68 gb and same of userdata.img.gz file of 337mb or 6.85gb
before recovering i did erased userdata and system by command
Code:
flashboot erase userdata
I had uncompressed userdata previously by following command as gz file cant be flashed
Code:
gzip -d -c /external_sd/userdata.img.gz | dd of=/dev/block/platform/7824900.sdhci/by-name/userdata
is there any problem with command of recovering
As df -h showing /dev/block/mmcblk0p29 866.5M of data in df -h
in my guess thoughts after rooting there is some space occupied in userdata
Code:
flashboot erase userdata
didnt erased the userdata and there is some background data left which has been not been erased and still occupying space in creating dump image file
safe way to delete erase unused space in userdata or block/mmcblk0p29
[*]the major concern is that i want to keep backup of my rooted and fully loaded phone and unrooted also so i want to decrease the size of image which after compressing is large
After googling i coundt find an safe command to compress the image now question is that should i fill the mmcblk0p29 block or userdata zero data with zero by following command kindly tell me the safest and best command from to get the appropriate command for the problem
fastboot erase userdata
Code:
rm -r /data/. or rm -r /sdcard/. c. dd if=/dev/zero of=/dev/block/platform/7824900.sdhci/by- name/userdata bs=8192
or
Code:
dd if=/dev/urandom of=/dev/block/platform/7824900.sdhci/by- name/userdata bs=8192
(but i could not find any /dev/zero or /dev/urandom in my dev direcotry)
newfs command to format the userdata partition but i dont know its options any other best safe command to solve the problem
kindly guide me to find the best safest and appropriate command to find solution for decreasing the size of userdata.img.gz and mmcblk0.img.gz for unrooted and rooted partitions if possible by adb shell or any other method
Click to expand...
Click to collapse
thank you in advance waiting for quick and urgent suggestions replies and advice