Database Info

Misuse of A2SD could damage your SD card!!

I've seen a lot of people complaining about not being able to boot after using A2SD for a while and I think it's definitely necessary to make clear the danger in using A2SD and some ways to prevents them.
Do not move /data/data to SD.
You can safely move /data/app and /data/app-private to SD. Be cautions with /data/dalvik-cache. (See below)
Make sure the ext2 partition are mounted with noatime and nodiratime (rom maker's job)
Do regular file system checks (using Linux)
Back up your ext2 partition and redo them regularly
Here're the theories:
(NAND) Flash memory has two serious limitations when used to store frequently changing data: you cannot do random write unless you erase a whole page first and any bit can only be written a limited number of times (typically a couple millions). When one bit in a page is detected to be faulty, you lose the whole page. (More details: http://en.wikipedia.org/wiki/Flash_memory#Limitations )
Most mobile os vendors overcome this problem by using special file systems, namely yaffs and jffs, which arrange files according to page size and do write operations only when necessary. They also provide journals so hardware faults could be reliably detected and corrected.
EXT2, which is the file system used in A2SD, DO NOT have these features. It may stupidly allow several pages to be erased hundreds of times of just to write some small files into it. Things are made even worse because some fixed part of the file system (inode table and bitmap) has to be written EVERYTIME a file operation is done. The will accelerate the wearing of those pages and when they become inaccessible, you lose the whole file system.
A2SD would work fine if you only move /data/app to it, because the application files are never modified. It is a completely different story for /data/data because the sqlite databases in there are modified almost every other second!! (And I suspect the OS commit them to disk very often to ensure data integrity.)
In addition, android does not have system check tools for ext2, so it will not be able to detect any problem with the file system until it’s too late.
Edit:
I am not sure how frequent the system updates files in dalvik-cache, but I would say you only move it when you are running out of space in /data.
(Also changed title)

billc.cn said:
I've seen a lot of people complaining about not being able to boot after using A2SD for a while and I think it's definitely necessary to make clear the danger in using A2SD and some ways to prevents them.
Do not move /data/data to SD.
Do regular file system checks (using Linux)
Back up your ext2 parition and redo them regularly
Here're the theories:
(NAND) Flash memory has two serious limitations when used to store frequently changing data: you cannot do random write unless you erase a whole page first and any bit can only be written a limited number of times (typically a couple millions). When one bit in a page is detected to be faulty, you lose the whole page. (More details: http://en.wikipedia.org/wiki/Flash_memory#Limitations )
Most mobile os vendors overcome this problem by using special file systems, namely yaffs and jffs, which arrange files according to page size and do write operations only when necessary. They also provide journals so hardware faults could be reliably detected and corrected.
EXT2, which is the file system used in A2SD, DO NOT have these features. It may stupidly allow several pages to be erased hundreds of times of just to write some small files into it. Things are made even worse because some fixed part of the file system (inode table and bitmap) has to be written EVERYTIME a file operation is done. The will accelerate the wearing of those pages and when they become inaccessible, you lose the whole file system.
A2SD would work fine if you only move /data/app to it, because the application files are never modified. It is a completely different story for /data/data because the sqlite databases in there are modified almost every other second!! (And I suspect the OS commit them to disk very often to ensure data integrity.)
In addition, android does not have system check tools for ext2, so it will not be able to detect any problem with the file system until it’s too late.
Click to expand...
Click to collapse
these are very good points. Actually come to think of it we better mount the ext2 partition with noatime. Because right now every read will wear the flash down. flash storage is really not meant for ext2 filesystem.

knaries2000 said:
these are very good points. Actually come to think of it we better mount the ext2 partition with noatime. Because right now every read will wear the flash down. flash storage is really not meant for ext2 filesystem.
Click to expand...
Click to collapse
In JF1.5 build it is mounted with noatime, i believe:
#mount
/dev/mmcblk0p2 on /system/sd type ext2 (rw,noatime,nodiratime,errors=continue)
But I totally agree with the point of the thread /data/data should not be moved to sd. Not that it's only dangerous (as described), I even don't see any advantages of it.

Dimath said:
In JF1.5 build it is mounted with noatime, i believe:
#mount
/dev/mmcblk0p2 on /system/sd type ext2 (rw,noatime,nodiratime,errors=continue)
But I totally agree with the point of the thread /data/data should not be moved to sd. Not that it's only dangerous (as described), I even don't see any advantages of it.
Click to expand...
Click to collapse
really. that's good, but I am running haykuro's build right now and it is not mounted with noatime. I will have to change the init script.

I'm using JF's 1.5 A2SD build, and I'm pretty certain I moved over /data/data. I didn't really ask myself the question when doing it, but what exactly is stored in /data/data? Is there a command I can run to move it back off the SD card?

Are ext2 and fat the only supported file systems in the android kernel? If not maybe it would be best to move to a wiser file system.

Rekna said:
Are ext2 and fat the only supported file systems in the android kernel? If not maybe it would be best to move to a wiser file system.
Click to expand...
Click to collapse
Yeah, why can't we use yaffs etc?

Dimath said:
Yeah, why can't we use yaffs etc?
Click to expand...
Click to collapse
i don't think most partitioners support yaffs
i know the partition manager on ubuntu 8.10 doesn't

tubaking182 said:
i don't think most partitioners support yaffs
i know the partition manager on ubuntu 8.10 doesn't
Click to expand...
Click to collapse
Indeed, and I'm fairly sure that's why it hasn't been done. But keep in mind several million write cycles is a heck of a lot and apps only really write their data caches occasionally, so it'll likely be a while before anything bad happens(on the scale of years) so this is slight sensationalism. Actually the term "cache" is a slight misnomer here since it's really just storage the apps use for temporary data. If it were used as some kind of extended RAM or a real cache then I could see problems but with what it's used for it should be a non-issue.

billc.cn said:
Here're the theories:
Click to expand...
Click to collapse
SD cards are a form of removable flash that have their own write controllers. In most cases, the write controllers also perform wear levelling. This means even if a program writes to the same file on the sd repeatedly, each time it writes, it is not writing the same physical location on the flash. The reason for this is because due to the way flash works, entire blocks have to be erased before they can be rewritten. To make writing faster, the memory controller keeps a list of empty blocks that are ready to use. When a file is changed, the entire file with the new changes is written to a new memory block and then the old block with obsolete data is then reset to zeros (data deleted).
That said, I still think A2SD is a red herring that only contributes to newbies spamming these forums.

jashsu said:
SD cards are a form of removable flash that have their own write controllers. In most cases, the write controllers also perform wear levelling. This means even if a program writes to the same file on the sd repeatedly, each time it writes, it is not writing the same physical location on the flash. The reason for this is because due to the way flash works, entire blocks have to be erased before they can be rewritten. To make writing faster, the memory controller keeps a list of empty blocks that are ready to use. When a file is changed, the entire file with the new changes is written to a new memory block and then the old block with obsolete data is then reset to zeros (data deleted).
That said, I still think A2SD is a red herring that only contributes to newbies spamming these forums.
Click to expand...
Click to collapse
Which is exactly why I made my new method that's able to deal with a lot of user mistakes and can be incorporated into ROMs to make it take almost 0 user effort

Dimath said:
Yeah, why can't we use yaffs etc?
Click to expand...
Click to collapse
yaffs on SD cards can in some common cases invalidate the wear leveling in hardware that SD cards do, as they so the wear leveling in software.
You are simply understimating ROM makers, SD cards are different from the internal flash in that they do auto wear leveling, that's why you can put common filesystems like FAT which have statically placed allocation tables and writes to the same logical sector will always land on very different places in the card every time.
Yes, noatime will help a lot as it will _reduce_ writes to your SD card.
ext2 is not journalled so it will have less writes too than ext3 or any other journalled filesystem.
So ROM makers are already doing a good job, don't understimate them please.

RyanZa's one click lag fix

Hi,
I was browsing the dev forum for the lag fix and I was wondering if anyone had any first hand experience using it on the Epic? I searched and didn't find anything substantial in this forum.
Thanks,

Tonythetigger said:
Hi,
I was browsing the dev forum for the lag fix and I was wondering if anyone had any first hand experience using it on the Epic? I searched and didn't find anything substantial in this forum.
Thanks,
Click to expand...
Click to collapse
It's not needed. Have you seen your Epic lag? If so, return it.

Well, it lags a little when I try to open barcode reader or the camera? I thought there was discussion on how the Epic would still receive a benefit from the lagfix..

Actually you can pretty easily make it lag. Take two pictures at full res and then go through gallery and attah them to gmail. Send. If you are not on wifi the phone litterally is paralyzed until its finished.
Those chose pooly on the formating

So has anyone used the lagfix?

I believe or partitions are different. That would most likely brick your device if used. I'm fqairly certain we could do the same for our devices but that's going to take time. Working recovery > that atm.

Aridon said:
Actually you can pretty easily make it lag. Take two pictures at full res and then go through gallery and attah them to gmail. Send. If you are not on wifi the phone litterally is paralyzed until its finished.
Those chose pooly on the formating
Click to expand...
Click to collapse
Well thats not fix with a LagFix. Thats a bug. It happens attaching it to anything. MMS, Gmail, Email, Facebook. Its a known bug.

Well my quadrant benchmark is 1k, shouldn't it be capable of going up to 2k?

I believe the lagfix will actually work, and may even help. I don't have an epic, so I can't test it at all.
Anyway, the I9000 has 8gb or 16gb internal memory. 2gb of that is dedicated to /data (data is where all your apps and their data go).
The epic has 2gb? 1gb? -- some amount of fast internal memory dedicated to /data.
Both the I9000 and your epic use the RFS filesystem, which appears to be very poor.
What the OCLF apk does is make a loopback EXT2 partition in your RFS filesystem, and then uses symlinks to make android put the apps/data inside the EXT2 partition. This should work fine on your epic, especially if you have 2gb of program memory! If you have less than 1gb it may be a problem though.
Feel free to try it out if you have rooted your device! (The I9000 root won't work on the Epic)

RyanZA said:
I believe the lagfix will actually work, and may even help. I don't have an epic, so I can't test it at all.
Anyway, the I9000 has 8gb or 16gb internal memory. 2gb of that is dedicated to /data (data is where all your apps and their data go).
The epic has 2gb? 1gb? -- some amount of fast internal memory dedicated to /data.
Both the I9000 and your epic use the RFS filesystem, which appears to be very poor.
What the OCLF apk does is make a loopback EXT2 partition in your RFS filesystem, and then uses symlinks to make android put the apps/data inside the EXT2 partition. This should work fine on your epic, especially if you have 2gb of program memory! If you have less than 1gb it may be a problem though.
Feel free to try it out if you have rooted your device! (The I9000 root won't work on the Epic)
Click to expand...
Click to collapse
Its 1Gb. But its not completely empty.
Also, I'm willing to test it. Do you have a link for the download?

Well the Epic has 512 ram and 512 rom, Froyo is supposed to allow the phone to use the SD card as install room for apps.
Would the lagfix run there?
Here is the link to the app: http://forum.xda-developers.com/showthread.php?t=760571

Fixter said:
Its 1Gb. But its not completely empty.
Also, I'm willing to test it. Do you have a link for the download?
Click to expand...
Click to collapse
It's on the market.
http://www.appbrain.com/app/com.rc.QuickFixLagFix
1GB... and yeah its obviously not empty, it has all your stuff in it!
Anyway with 1GB is might be a bit tight, as that would leave only 500mb or so for apps.
Make a backup before you test it though, since I think you're the first person to test it on the Epic. It should refuse to run if there is anything wrong though.

So if the phone can use the SD card for /data would the fix have more space there? Or would we just get more space to install and run apps

RyanZA said:
It's on the market.
http://www.appbrain.com/app/com.rc.QuickFixLagFix
1GB... and yeah its obviously not empty, it has all your stuff in it!
Anyway with 1GB is might be a bit tight, as that would leave only 500mb or so for apps.
Make a backup before you test it though, since I think you're the first person to test it on the Epic. It should refuse to run if there is anything wrong though.
Click to expand...
Click to collapse
It says Unavailable.

Tonythetigger said:
Well the Epic has 512 ram and 512 rom, Froyo is supposed to allow the phone to use the SD card as install room for apps.
Would the lagfix run there?
Here is the link to the app: http://forum.xda-developers.com/showthread.php?t=760571
Click to expand...
Click to collapse
512MB is going to be too little.
You can actually get around this with a fast SD card though! If you know how to use gparted, you can make a 2GB or so EXT2/3 partition on your SD card, and then copy your data across to that, and use symlinks to point Android there. With the Epics fast NAND though, this shouldn't be necessary for speed - but it might be really nice for you guys if you want to install a lot of apps!
EDIT: You can follow mimocan's tutorial here: http://forum.xda-developers.com/showthread.php?t=724251
Just don't use EXT4 since your kernel won't support it. There is a way to dynamically load the EXT4 kernel module though, if anybody is interested.

RyanZA said:
512MB is going to be too little.
You can actually get around this with a fast SD card though! If you know how to use gparted, you can make a 2GB or so EXT2/3 partition on your SD card, and then copy your data across to that, and use symlinks to point Android there. With the Epics fast NAND though, this shouldn't be necessary for speed - but it might be really nice for you guys if you want to install a lot of apps!
Click to expand...
Click to collapse
Thats weird.. On the Samsung Specsheet is says 1Gb. I saw it not 30 minutes ago.
EDIT: User Memory 1GB (not all is usable for customer use/downloads)

DAMN IT! I'm sure Touchwiz is using the other 500Mb.

Here's a link to the dev page, you can download the app directly from there: http://forum.xda-developers.com/showthread.php?t=760571

lag fix?
SDcard-using lag fix is obviously unnecessary for Epic 4G.
The reason why Epic has a small NAND chip is that it uses a different type of NAND, called "OneNAND." OneNAND is much much faster than normal NAND or moviNAND (which other Galaxy S's use).
This is why Epic users don't experience "lag" which exists in Vibrant or Captivate.
But we can still make Epic faster, by getting rid of Samsung's rfs file system (which obviously makes Vibrant/Captivate slower) and mounting ext3/4 or other faster file system.
Then we need:
1) patching kernel or adding module to support ext3/4/nilfs2/yaffs2/ubifs/btrfs/etc/whatever we want.
(ext2 is supported by the stock kernel I think. However, unlike SD card and moviNAND which have own hardware wear-leveling algorithms in their controllers, OneNAND does not has it, so I'm not sure if ext2 (which does not support journaling/log) is okay to use.)
2) backing up the partitions which we want to change the file system from rfs
(such as: /data/data, /data/app, /data/dalvik-cache, etc, whatever)
and finally formatting it to what we want, and mount it.
3) kernel or script that automatically mounts as the file system we want.
4) a genius who can do this. (It is obviously not me.)
This is done for Captivate in XDA forum, and also for Galaxy S M110S in a Korean forum.

chocoberry said:
SDcard-using lag fix is obviously unnecessary for Epic 4G.
The reason why Epic has a small NAND chip is that it uses a different type of NAND, called "OneNAND." OneNAND is much much faster than normal NAND or moviNAND (which other Galaxy S's use).
This is why Epic users don't experience "lag" which exists in Vibrant or Captivate.
But we can still make Epic faster, by getting rid of Samsung's rfs file system (which obviously makes Vibrant/Captivate slower) and mounting ext3/4 or other faster file system.
Then we need:
1) patching kernel or adding module to support ext3/4/nilfs2/yaffs2/ubifs/btrfs/etc/whatever we want.
(ext2 is supported by the stock kernel I think. However, unlike SD card and moviNAND which have own hardware wear-leveling algorithms in their controllers, OneNAND does not has it, so I'm not sure if ext2 (which does not support journaling/log) is okay to use.)
2) backing up the partitions which we want to change the file system from rfs
(such as: /data/data, /data/app, /data/dalvik-cache, etc, whatever)
and finally formatting it to what we want, and mount it.
3) kernel or script that automatically mounts as the file system we want.
4) a genius who can do this. (It is obviously not me.)
This is done for Captivate in XDA forum, and also for Galaxy S M110S in a Korean forum.
Click to expand...
Click to collapse
Thank you for the explanation. Now lets wait for the genius.

[Q] freeing up space on galaxy s 4g

I know this issue has been more or less beat to death, trust me one google search proves that. and after 2 1/2 days searching and researching I have come up with an idea to rid us of this limited application space problem once and for all. At this point I am stuck realizing that android doesn't use an fstab file like any ol' standard linux install....so what's the android equivalent?
a little explaination....
I came across a solution used on another phone where via a custom rom someone was able simply hardlink /data/app, /system/media, etc... to a copy stored on a ext2/3/4 partition on the sd card, I guessed roughly 2~3 gb of space would be sufficient. I created the partition, copied the folders, and just before I was going to start hardlinking things, I realized I had to manually mount the ext2 partition, it wasn't done automatically, and therefore won't be done at boot. So...this is where I'm stuck. if I could figure out how to get the ext2 partition to mount at boot then problem solved
Any thoughts, suggestions, ideas, etc would be appreciated. I apologize in advance if I may have missed something someone may seem as "obvious"....I've been at this for over 2 days reading more webpages than I care to recount and quite frankly my brain is fried.....so please keep the "flaming" to a minimum...

dude just overwrite the FOTA files and it will free up 250mb.

Are you sure you searched these forums? It's in the dev section.

did the fota fix, got about 290mb free (already done before I posted this). call me greedy but ~300 mb just seems not quite enough.....my solution sounds simple enough if I could only fix that blasted mount on boot issue....
as for searching, I apologize but I viewed so many pages yesterday that I couldn't possibly list them all, but fota was one of them and already done.....I'm looking for a more permanent solution (assuming that ota updates will become available for this phone before it becomes obsolete)

Wouldn't that have to be a script initiated by the kernel? I could be way off, but it seems like thats how they fixed the problem with the G1 app mem issue using cm. You might read on cm+G1. Like the way your thinking though!
Check THIS out. I think it's along the right lines, if it could be ported.

Not sure what you think needs more than a few hundred MB in the "real" mount of /data.
Several ways you can install other apps on the SD card, both native using package manager (pm), as well as using tools like app2sd without a custom kernel and boot sequence.

[Q] Making Swapfile on Gtab 7+?

hi guys,..
i want to ask is there any way i can make swapfile on gtab 7+ running hc 3.2? or there is no posibility to make swapfile on honeycomb? i've tried to make the swapfile using dd command from terjinal, but somehow im stucked on setting permission for the file, the file i've created always have special permission that i can't change to rw-r-r, it always stayed rw-rSw-r, im a newbie on linux things, and willing to learn.
any help really appreciate.
thanks.

Okay, you say that you're a newbie to linux. That's fair and reasonable. I'm going to try and teach you some things by way of asking questions. They might sound like I'm attacking you, but I'm not...
Do you know you are trying to create a swap file? What do you hope to gain by doing so?
Is this one of those mythical magical things that someone claims will make the tablet run 50395920 times faster, allow it to brew coffee, and make your car get better fuel mileage?
...and some answers...
Within the android environment, a swap file is a BAD THING. The entire system is designed to drop stuff out of memory if/when it needs more memory, and the overhead of a swapfile will cause more harm than good.
Take care
Gary

garyd9 said:
Within the android environment, a swap file is a BAD THING. The entire system is designed to drop stuff out of memory if/when it needs more memory, and the overhead of a swapfile will cause more harm than good.
Click to expand...
Click to collapse
It's not that dramatic. Most of "the overhead of a swapfile" is overhead you're already committing to by utilizing a VMM (Virtual Memory Manager). The Dalvik VM doesn't do a whole lot of its own memory management so implementing a swapfile at the OS level, which is what the OP is looking to do, wouldn't have a huge impact on performance.
The only time where you'd have any real overhead of maintaining a swapfile is when memory is full and the OS pages out memory to disk. But remember that the alternative is to close down the process and run some garbage collection. Both are intensive actions - swapfile is I/O intensive while GC is CPU and memory intensive - so you're really trading one source of overhead for another.
To answer the OP's question, it sounds like you haven't rooted the tab. You would need to be root in order to change the perms as you described. If you are rooted, make sure you're using the right command to set permissions - I haven't tried this specifically on Android but from my *nix experience, the command you want is chmod 644 <path to file>
---------- Post added at 09:24 PM ---------- Previous post was at 08:39 PM ----------
Almost forgot, what kernel are you using?

im using stock kernel 2.6.36, kk6 rooted. i've tried to chmod the swapfile, but still cant change the permission, i usually use root explorer to change the permission, but now it doesn't take effect. the file permission r8 now is rw-rwSr--, the "S" thing is making the swap cant be aplied (i guess).
back there when i use optimus (gingerbread), swapfile is default from stock rom. is it have something to do with honeycomb?
thanks for your reply.

garyd9 said:
Okay, you say that you're a newbie to linux. That's fair and reasonable. I'm going to try and teach you some things by way of asking questions. They might sound like I'm attacking you, but I'm not...
Do you know you are trying to create a swap file? What do you hope to gain by doing so?
Is this one of those mythical magical things that someone claims will make the tablet run 50395920 times faster, allow it to brew coffee, and make your car get better fuel mileage?
...and some answers...
Within the android environment, a swap file is a BAD THING. The entire system is designed to drop stuff out of memory if/when it needs more memory, and the overhead of a swapfile will cause more harm than good.
Take care
Gary
Click to expand...
Click to collapse
thanks m8 for your lighten up of linux, i really appreciate it. just from my experient when im using optimus (gingerbread) i never felt lack of memory when using multitasking (it only has 512mb ram). but now when i using gtab (with 1gb ram or 778mb?) first it fast on multitasking but about 10 minute later it getting slower, when i check with task manager, it only has 80mb left??
is it me or is it gingerbread have better ram management than honeycomb, and so if it is, im trying to make swapfile in hope that its getting better. i use v6 supercharger, kill all proccess when it turn to standby by automatic, overclocking to 1,6ghz, but still i can make the ram more efficient when running on multitasking.
hope you understand for what im going to achieve.
thanks.

h2g2 said:
It's not that dramatic.
Click to expand...
Click to collapse
Are you suggesting that using an OS-level "generic" swapfile on flash memory is better or even equivalent to using a system/purpose built solution?
The linux kernel has no way to know if the memory its swapping out is even needed anymore. The android system, however, does know this - and will often discard allocations.
Let's say you run two applications: email and the browser. The browser has several pages loaded with flash, and lots of memory intensive stuff going on. Also in memory is the code that syncs your email in the background and several other "non critical" services (such as SMS, latitude, etc.) and a few critical services (such as some wifi support, display support, framework, etc.)
Keep in mind that if android requests memory, and there's a swapfile, the kernel will claim it has memory backed by swap... So given a large enough swapfile, the kernel will never tell android that it's running short on memory...
Given the above situation, the user now wants to run Angry Birds. There isn't enough physical RAM to support all of the above in memory AND Angry Birds. What will happen?
If there's no swapfile, android will see there isn't enough RAM to support it, and simply drop the browser and email client from memory, but keep the services in memory. Angry birds loads, and the user is happy.
IF there IS a swapfile, however, then android will see that there is RAM to support AB along with everything else in memory, and just load Angry Birds. When that happens, the linux kernel will have to swap pages of memory out to the flash memory. The KERNEL doesn't know the difference between the email client, the email service, the browser, or any other "non-critical" service. All those memory pages are flagged the same. So, perhaps the browser gets swapped out. (wasted cycles - it could have been discarded.) The email client is retained in RAM, but the email service is swapped out to flash. Angry Birds loads. 5 minutes later, Angry Birds freezes and gets jumpy... why? Because the email service has to be swapped back into RAM, and something else swapped out in its place. This time it was latitude. A few minutes later, latitude wants to update your position, so the same thing happens. What gets swapped this time?
Why spend the cycles swapping things in and out of RAM? There is plenty of memory on these devices to support all the services and memory hungry games. If some game has a memory leak, you SHOULD be getting errors from running out of memory and NOT blissfully swapping things to flash.
I'm not going to tell people how to use their devices. I'm going to try and give them advice, but I certainly can't force people to take it. As a matter of fact, I'll even encourage the technical minded to explore and break things to learn on their own.
However, when a person asks the question I see in the OP, and admits that they are new to linux, then I suspect that they aren't technically minded and exploring, but blindly following the "suggestion" of someone else who promises all kinds of silly things. It reminds me of someone who disabled kernel panic reboots and claimed that it was a tweak to make the system more stable... and had many people actually believing that.
There's a good reason why google hasn't enabled swapping, and there's even less of a reason with devices that come with 1GB of RAM.
Take care
Gary
---------- Post added at 01:45 AM ---------- Previous post was at 01:25 AM ----------
danielkaboom said:
is it me or is it gingerbread have better ram management than honeycomb, and so if it is, im trying to make swapfile in hope that its getting better. i use v6 supercharger, kill all proccess when it turn to standby by automatic, overclocking to 1,6ghz, but still i can make the ram more efficient when running on multitasking.
hope you understand for what im going to achieve.
thanks.
Click to expand...
Click to collapse
First of all, try the same thing without that "supercharger" script. I've made clear my thoughts on that. In this case, using that script may or may not be allowing HC to do what its designed to do in regards to memory management. I'm not saying you should delete it - but to run tests without it.
If you are running low on FREE memory, that's not a bad thing. What good is the memory doing if it's not being used? Android will let an unused application linger in RAM as long as they wants so long as nothing else needs that RAM. As soon as something else needs that RAM, those unused apps will be purged (garbage collection.)
Having a swap file directly contradicts any effort to purge things from memory. A swapfile will encourage the system to swap things to flash as virtual memory. Sure, your "free memory" number might be bigger, but it will slow the system down when it's swapping things out to and in from flash memory. (A blunt question Are you chasing numbers or actual performance?
How do you expect to make memory MORE efficient by always having it be unused? Memory that's not being used is wasted. If my desktop machine (that has 16GB of RAM) has only 6GB being used, then I have 10GB of RAM wasted. I'd rather that memory be used to store an application I might go back to using, or used as cache. Completely unused RAM is completely wasted RAM.
I understand that you might be caught up in the whole thing with overclocking, having as much free RAM as possible, and having nice benchmark numbers. The thing is.. NONE OF THAT MATTERS.
Want higher benchmark numbers? I can make you a kernel that will give you insanely high numbers. Your device will suck for actual use, but you'll get high benchmarks.
Want a big "free RAM" number? Never run any apps, never get email, don't do anything at all with the device. It'll be an expensive paperweight, but you'll always have lots of free (and completely wasted) RAM.
Try this: make a backup of your system and then go back to stock. Use your tablet in a factory state for a few days. Then root it and disable some of the things that might be chewing the battery. Don't overclock, don't install scripts, and don't install a custom kernel. Use the device like that for a while. Actually USE the device - don't benchmark it, check task managers, etc. Just use it.
Now, how does it feel? No script, kernel, or anything else will make a dramatic performance increase. They can (and often do) make things slower, however. (That's why I'm very careful about modifications I make to my kernel...)
After using it stock for a few days, come back and tell us what you think - what you wish would be better in actual day to day use. (Again, benchmarks and numbers don't mean much...)
Take care
Gary

yes Gary,...to be honest, im blindly follow every1 that claims can tweaks or anything like tha, but when i tested it and using it, if its making my device getting "better" i kept it, if its making it worse than before, i let go.
in my opinion, slow, fast or faster is relative, it depends on every1 needs. for me loading game such as finalstrike hd in 5 sec is fast, but maybe different to others by loading it 20-30 sec is acceptable.
but if you said swapfile is bad and will only making it worse, then i'll accept that, but after im testing it. for me, sugar is not sweet until my tounge said so, no offence.
again, thanks Gary for the explanation, thanks for opening my mind.
edit : ill try to follow your instruction first.

You should do what you feel like, but please don't get caught up in lots of people telling you that they have magic bullets to fix things (that really aren't even broken.)
That being said, you are having a technical problem and I just can't resist information sharing.
What directory are you trying to create the file in? /sdcard (or /mnt/sdcard) won't work.
Try /data
(/mnt/sdcard == /sdcard.. and they will force certain permissions via fuse/vold.) Unlike GB, with HC /data and /mnt/sdcard use the same space. (/mnt/sdcard is actually a fuse from /data/media.) (In GB, /data space was very limited. That's not the case with HC.)
Gary

still failed,...:
- create a file in /data (named swapfile.swp), using terminal
# dd if=/dev/zero of=/data/swapfile.swp bs=1024 count=128000
- check from root explorer, the file is now created.
# mkswap /data/swapfile.swp
# swapon /data/swapfile.swp
swapon /data/swapfile.swp = Function not implemented
any sugestion?
edit : the permission is now can be change to rw-r--r--(thx Gary)..but its still failed to swapon,..
edit 2 : from what i've read from other pages and sites,..is it because "kernel not support"?

garyd9 said:
Are you suggesting that using an OS-level "generic" swapfile on flash memory is better or even equivalent to using a system/purpose built solution?
Click to expand...
Click to collapse
There is no "system/purpose built solution" - the Dalvik VM uses the Linux kernel VMM functions for low level memory management (http://developer.android.com/guide/basics/what-is-android.html).
The linux kernel has no way to know if the memory its swapping out is even needed anymore. The android system, however, does know this - and will often discard allocations.
Click to expand...
Click to collapse
Yes it does. The VMM knows which pages are active, which are inactive, and - if an application has called free() on a pages it previously malloc()'d, it will know which pages are expired.
In fact, the VMM will often know more than the Dalvik VMs because each application runs in its own Dalvik thread with its own dedicated heap. Any individual Dalvik instance will only know the disposition of the heap for its own application.
The VMM, on the other hand, has visibility of all Dalvik threads and will know which threads are idle and which are active, which Dalvik threads have run garbage collection and free()'d a portion of their heap, etc.
Keep in mind that if android requests memory, and there's a swapfile, the kernel will claim it has memory backed by swap... So given a large enough swapfile, the kernel will never tell android that it's running short on memory...
Click to expand...
Click to collapse
No, it won't. That's not how the swapfile works. What you're describing is more akin to memory-mapped file I/O, which is related (in that the VMM plays a role in managing that address space) but not at issue (it's a completely separate operation from memory allocation and de-allocation).
Memory is requested by giving the kernel a malloc() command. The VMM will then check its page cache (the size of which is constrained by physical memory - regardless of whether there is a swapfile or not) and look for available space. If space isn't available, then the VMM will look for pages marked as expired. If there aren't enough expired pages, it will look for inactive pages (pages allocated by processes that are idle or supsended).
At this point, the VMM will either 1) discard the contents of the expired and/or inactive pages until enough free pages are available (if no swapfile is available) or 2), write the contents of the expired and/or inactive pages to the swapfile before discarding them until enough free pages are available.
Note that the presence or absence of the swapfile has no bearing on what pages are chosen. And again, regardless of whether there is a swapfile or not, if there aren't enough expired and/or inactive pages to get rid of, malloc() returns a null pointer. In otherwords, you will get out of memory errors even with a giant swapfile.
Given the above situation, the user now wants to run Angry Birds. There isn't enough physical RAM to support all of the above in memory AND Angry Birds. What will happen?
If there's no swapfile, android will see there isn't enough RAM to support it, and simply drop the browser and email client from memory, but keep the services in memory. Angry birds loads, and the user is happy.
IF there IS a swapfile, however, then android will see that there is RAM to support AB along with everything else in memory, and just load Angry Birds. When that happens, the linux kernel will have to swap pages of memory out to the flash memory. The KERNEL doesn't know the difference between the email client, the email service, the browser, or any other "non-critical" service. All those memory pages are flagged the same. So, perhaps the browser gets swapped out. (wasted cycles - it could have been discarded.) The email client is retained in RAM, but the email service is swapped out to flash. Angry Birds loads. 5 minutes later, Angry Birds freezes and gets jumpy... why? Because the email service has to be swapped back into RAM, and something else swapped out in its place. This time it was latitude. A few minutes later, latitude wants to update your position, so the same thing happens. What gets swapped this time?
Click to expand...
Click to collapse
So bearing in mind that the Linux kernel VMM is ultimately responsible for choosing what gets dropped or swapped out of memory and also bearing in mind that only inactive or expired pages are eligible to be dropped/swapped, we can see that the situation you describe will never happen.
The behavior of, from the user's perspective, what applications get shoved out of active memory (regardless of whether they end up in the swapfile or in /dev/null) doesn't change. In the same way that the Linux VMM will never drop pages associated with an active process (such as the email sync service, the Wifi driver, etc), the Linux VMM will likewise never swap these pages out either.
Why spend the cycles swapping things in and out of RAM? There is plenty of memory on these devices to support all the services and memory hungry games. If some game has a memory leak, you SHOULD be getting errors from running out of memory and NOT blissfully swapping things to flash.
Click to expand...
Click to collapse
Consider the scenario you spelled out previously - without the swapfile, the pages associated with the Browser app will get dropped and make room for Angry Birds. Good news: Angry Birds starts up faster.
With the swapfile, the pages associated with the Browser app will get swapped out to make room for Angry Birds. This will take longer since there's some file I/O involved. Bad news: Angry Birds starts up slower.
So what's the use case for the swapfile? What if you want to go back to the browser again? Without the swapfile, the Browser is gone. You have to launch it - the application binary needs to be read off disk, executed, the heap has to be re-allocated, re-initialized, and program data needs to be populated. The page you wanted is gone - you need to fetch that again. More waiting while it downloads from the server and the HTML code is rendered on the screen.
In this scenario, reading the heap back into memory from the swap file is actually more efficient than recreating it - even if you ignore the obvious benefit of not having to relaunch the app and reload the page, there's substantial overhead associated with relaunching the app.
So that's the use case - maybe it's not applicable to you if (although maybe someone who wants to go back and forth between Angry Birds and a cheat guide on a G1 might appreciate this) but if you are multitasking across several memory-intensive apps, then the benefit of not having to re-invent the wheel, so to speak, to recover the application state can outweigh the cost of paging the application state out to disk.
I'm not going to tell people how to use their devices. I'm going to try and give them advice, but I certainly can't force people to take it. As a matter of fact, I'll even encourage the technical minded to explore and break things to learn on their own.
However, when a person asks the question I see in the OP, and admits that they are new to linux, then I suspect that they aren't technically minded and exploring, but blindly following the "suggestion" of someone else who promises all kinds of silly things. It reminds me of someone who disabled kernel panic reboots and claimed that it was a tweak to make the system more stable... and had many people actually believing that.
Click to expand...
Click to collapse
I have no problem with dissuading people of the notion that some hack is going to instantly and unequivocally make their system better. But I think the proper response, especially on a forum like this, is to present the facts of the matter and not just a knee-jerk contrarion reaction. Simply dismissing the swapfile as a "BAD THING" doesn't really help the OP learn more about it, at the very least.
I'm with you on disabling kernel panic reboots, though. That's just stupid.
There's a good reason why google hasn't enabled swapping, and there's even less of a reason with devices that come with 1GB of RAM.
Click to expand...
Click to collapse
Maybe, maybe not. Android 2.1 and earlier didn't implement JIT. Android 2.2 and earlier didn't implement EXT4. Android 2.3 and earlier didn't implement GPU-accelerated UI compositing. Android 3.2 and earlier didn't implement ASLR. Does that mean these were considered undesirable by Google at one point in time? Or were they always on Google's list of things they wanted to do and they just hadn't gotten around to them yet?
---------- Post added at 01:56 AM ---------- Previous post was at 01:41 AM ----------
danielkaboom said:
still failed,...:
- create a file in /data (named swapfile.swp), using terminal
# dd if=/dev/zero of=/data/swapfile.swp bs=1024 count=128000
- check from root explorer, the file is now created.
# mkswap /data/swapfile.swp
# swapon /data/swapfile.swp
swapon /data/swapfile.swp = Function not implemented
any sugestion?
edit : the permission is now can be change to rw-r--r--(thx Gary)..but its still failed to swapon,..
edit 2 : from what i've read from other pages and sites,..is it because "kernel not support"?
Click to expand...
Click to collapse
Yes, the kernel needs to have swapfs support. If you've ever played around with EXT4 kernels or ROMs that required EXT4 kernels, for example, it's kind of the same idea.
It sounds like the stock GT7+ kernel does not have this so you will need to find a custom kernel that does. I'm going to go out on a limb and guess that garyd9's kernel does not support swapfs.
Without the kernel, you're out of luck.
Regarding your situation on your Tab, it sounds like you've got an app or two that's misbehaving. Have you tried throwing up a CPU monitor? It would be useful to know whether the slowdown is caused by the CPU getting busy, and whether this load is from a single app or not.

Thank you for explaining that. Are there any examples, other than the one you mentioned, in which Android would benefit from a swapfile?

reading both pros and cons about swapfile really makes my head spinning,... im trying to understand it little by little. thanks guys for the explanation.
and yeah, guess im run out of luck,..(cause i don't have enough skill to make the kernel on my own,..sigh).
thanks.

danielkaboom said:
reading both pros and cons about swapfile really makes my head spinning,... im trying to understand it little by little. thanks guys for the explanation.
and yeah, guess im run out of luck,..(cause i don't have enough skill to make the kernel on my own,..sigh).
thanks.
Click to expand...
Click to collapse
It is a complicated issue with lots of tradeoffs in both directions.
I'm still curious as to the specifics of your problems, though. Garyd9 is correct in saying that creating a swapfile may not help your particular issue but that doesn't mean there isn't some other way to fix it. We just need more information about what's going on on your tablet.
---------- Post added at 05:49 PM ---------- Previous post was at 05:29 PM ----------
nyarltep said:
Thank you for explaining that. Are there any examples, other than the one you mentioned, in which Android would benefit from a swapfile?
Click to expand...
Click to collapse
Fundamentally, it breaks down to a store vs. recalculate issue - do you store memory pages to the swap file and incur the storage I/O overhead or do you discard it and recalculate it later and incur the cpu and memory I/O overhead? All of these resources are in short supply on the GT7+.
A swapfile works best with applications that maintain steady states that can easily be swapped out and back in as needed. A swapfile is least effective for active background processes.
If, for example, you're running out of memory running too many apps in the background - think clients for sync services, streaming media, system monitoring, etc. - a swapfile is not going to help.
However, if you're running into situations where you are switching between multiple apps such as document viewers/editors, and are finding that you need to reload documents as the apps get silently killed in the background, a swapfile could potentially help.
The only real way to know is to test it but without a kernel with swapfs support for the GT7+, it's impossible to say for certain.

from the opinion, i guess using swapfile for backround process is useless, but using it to switching task (for example : im using browser with lot of pages and beside that im doing some paperwork on office aplication) will help a bit, am i r8? if its r8, then im willing to try using swapfile, because i already freeze/uninstall some aplication that running on backround but still give me lags, when i did the example above.
but again, im running out of luck,..until Garyd9 or any1 else kind enough to make kernel that support swapfs,...
thanks for both of you, for your effort to answering my noob question.
regards,
dan
PS : Gary, i've tried your instruction, and yes it makes my daily use better,...though im still curious using swap,...hehehe.

danielkaboom said:
from the opinion, i guess using swapfile for backround process is useless, but using it to switching task (for example : im using browser with lot of pages and beside that im doing some paperwork on office aplication) will help a bit, am i r8? if its r8, then im willing to try using swapfile, because i already freeze/uninstall some aplication that running on backround but still give me lags, when i did the example above.
but again, im running out of luck,..until Garyd9 or any1 else kind enough to make kernel that support swapfs,...
Click to expand...
Click to collapse
Background processes are fine to swap out if they're steady state, it's active background processes that aren't going to benefit from a swapfile.
However, the lags you're experiencing may continue to persist depending on what is causing those lags. A swapfile won't help if you've got a poorly-optimized app running, particularly one that is not efficient with memory allocations. It also won't help if the lags are caused by a Dalvik thread performing garbage collection on its heap (whether the app on that thread is efficient in its memory allocations or not).
My educated guess is that if you are experiencing lags while using an active, foreground application, then this is not a problem that will be fixed with a swapfile. On the other hand, if you are experiencing lags launching new applications or bringing background apps into the foreground, these types of lags may be reduced with the use of a swapfile though the only way to know for sure is to test it.

I don't have time for an indepth reply to h2g2, but I'll reply simply:
You seem to be knowledgable enough to recompile a kernel - so please feel free to pull my kernel sources and initramfs, turn on swapping (samsung has it disabled by default), and try it. Keep an eye on the swapping and memory stats, as well as what's being swapped, etc... You might be surprised.
(If I had time, I'd do the same.. I've been wrong before and I might be wrong again... )
In either case, Daniel, I'm glad that turning off all that excess crap helps. As much as we all complain about this tablet, it actually runs pretty good without many modifications. If you read the changes I've made in the p6210 kernel, you'll see that I really haven't done much to it. The most invasive change was adding stuff that Samsung didn't have in there (such as UV.)
Take care
Gary

garyd9 said:
I don't have time for an indepth reply to h2g2, but I'll reply simply:
You seem to be knowledgable enough to recompile a kernel - so please feel free to pull my kernel sources and initramfs, turn on swapping (samsung has it disabled by default), and try it. Keep an eye on the swapping and memory stats, as well as what's being swapped, etc... You might be surprised.
(If I had time, I'd do the same.. I've been wrong before and I might be wrong again... )
Click to expand...
Click to collapse
Just to be clear, I have no real stake in this except to make sure that the technical facts about the swapfile are presented properly. In much the same way that you've been frustrated hearing about people recommending that they disable kernel panic reboots, I also am frustrated when people have a knee-jerk "swapfile = terrible" reaction that is largely based on FUD.
That said, you're right, I should just test it myself when I've got some free time.

Dusted off my old Nexus One, loaded up a clean install of CM7 and installed a kernel with CONFIG_SWAP=y. I decided to go with a swap partition on my sd card rather than a swapfile but the effect should be the same.
I haven't had time to do extensive testing but so far but I can confirm that swap is working and I haven't yet noticed a major perceptible impact to performance of the device.
Code:
# free
total used free shared buffers
Mem: 403240 379288 23952 0 60
-/+ buffers: 379228 24012
Swap: 62696 27948 34748
# grep "pswp" /proc/vmstat
pswpin 192
pswpout 7059
---------- Post added at 01:37 PM ---------- Previous post was at 12:49 PM ----------
Been switching back and forth between apps for a while now, paying particular attention to apps like Google Earth and the Browser that load up lots of data.
One particular test that seemed to stress the memory subsystem was using the "Print this page" on multi-page articles on graphics-heavy sites like, e.g. Anandtech (had the Snapdragon S4 review up). With swap enabled, there was a delay of 1-2 seconds when switching back to the browser (no doubt from reading the appropriate pages back into memory) but without the swapfile, the session was gone and the page needed to be reloaded, which took much longer than 1-2 seconds.
Some caveats:
1) I used a rather small swap partition (64MB) compared to the amount of memory available on the device (512MB for the N1). This means that I didn't need to do too much tweaking to the lowmemorykiller settings.
2) I set swappiness to 100, which is intentionally a bit heavy-handed (default seems to be 60).
3) I did not tweak other settings such as dalvik.vm.heapsize, vfs.
_cache_pressure, page-cluster and, as mentioned in #1, lowmemorykiller/parameters/minfree.
Code:
# free
total used free shared buffers
Mem: 403240 390824 12416 0 36
-/+ buffers: 390788 12452
Swap: 62696 59684 3012
# grep "pswp" /proc/vmstat
pswpin 6061
pswpout 31228

h2g2 said:
Dusted off my old Nexus One, loaded up a clean install of CM7 and installed a kernel with CONFIG_SWAP=y. I decided to go with a swap partition on my sd card rather than a swapfile but the effect should be the same.
I haven't had time to do extensive testing but so far but I can confirm that swap is working and I haven't yet noticed a major perceptible impact to performance of the device.
Code:
# free
total used free shared buffers
Mem: 403240 379288 23952 0 60
-/+ buffers: 379228 24012
Swap: 62696 27948 34748
# grep "pswp" /proc/vmstat
pswpin 192
pswpout 7059
---------- Post added at 01:37 PM ---------- Previous post was at 12:49 PM ----------
Been switching back and forth between apps for a while now, paying particular attention to apps like Google Earth and the Browser that load up lots of data.
One particular test that seemed to stress the memory subsystem was using the "Print this page" on multi-page articles on graphics-heavy sites like, e.g. Anandtech (had the Snapdragon S4 review up). With swap enabled, there was a delay of 1-2 seconds when switching back to the browser (no doubt from reading the appropriate pages back into memory) but without the swapfile, the session was gone and the page needed to be reloaded, which took much longer than 1-2 seconds.
Some caveats:
1) I used a rather small swap partition (64MB) compared to the amount of memory available on the device (512MB for the N1). This means that I didn't need to do too much tweaking to the lowmemorykiller settings.
2) I set swappiness to 100, which is intentionally a bit heavy-handed (default seems to be 60).
3) I did not tweak other settings such as dalvik.vm.heapsize, vfs.
_cache_pressure, page-cluster and, as mentioned in #1, lowmemorykiller/parameters/minfree.
Code:
# free
total used free shared buffers
Mem: 403240 390824 12416 0 36
-/+ buffers: 390788 12452
Swap: 62696 59684 3012
# grep "pswp" /proc/vmstat
pswpin 6061
pswpout 31228
Click to expand...
Click to collapse
little of my understanding, if a swapfile is made in an external sd, the sd card must have good r/w capability (minimum required a class 6 sd card), what if the swapfile is made in internal sd (since GTab have 12gb planted chip memory), what is the effect?
and so,....would you be kind enough to build a kernel for GTab 7+ that support swapfile? and if you do, can you do with a flashable zip (which i can flash it through cwm recovery?
so i can answer my own question : swap or not to swap?
and of course if you have spare time
thanks
dan

danielkaboom said:
little of my understanding, if a swapfile is made in an external sd, the sd card must have good r/w capability (minimum required a class 6 sd card), what if the swapfile is made in internal sd (since GTab have 12gb planted chip memory), what is the effect?
and so,....would you be kind enough to build a kernel for GTab 7+ that support swapfile? and if you do, can you do with a flashable zip (which i can flash it through cwm recovery?
so i can answer my own question : swap or not to swap?
and of course if you have spare time
thanks
dan
Click to expand...
Click to collapse
I'm using a Class 2 8GB MicroSDHC card from Sandisk on my Nexus One for testing and it seems to be fine. I'd recommend using an external SD because it's replaceable and swap I/O will wear out your flash faster so you're better off segregating it.
I took a look at the state of the kernel source for the GTab7+ at the moment and it looks like the Samsung sources are out of date and a kernel built from the current sources won't run properly on the LA3 firmware (Garyd9 notes this in the thread for his kernel as well) so right now, building a custom kernel is a nonstarter for me because the LA3 firmware fixed some pretty major shutdown issues for me on my Tab.
Perhaps when the ICS sources are released, I'll take another look.

Secure Deletion

A few weeks ago there was something on the UK news about smart phone data and how when you sell/recycle your phone most people leave accessible data on the phone after a factory reset. There was lots of trying to shock people (reading out text messages and browser history) but the solutions were barely discussed, all that was said was something like "There are programs that can overwrite your data"
So what do people do when they sell their android phone? I've seen an app in the play store called nuke my device, it basically overwrites the internal SD card then does a factory reset, I'm still not sure that would totally erase all data though?

I know all about methods for PC hard drives, but I too wouldn't mind knowing how android systems should be handled.

Yeah I know about PC Hard drives too. I have bought the nuke my device app from the play store, its cheap, I haven't used it yet!

To block undeleters it's sufficient to fill space with "generic" data then delete the file
As for removing the chip and using an external programmers, some indeed expose raw memory over the pins (MTD chips) and there's no reasonable way to wipe the hidden areas (well, assuming you want a device that still works - otherwise there's the Cobra 6 method), others have on-chip mappers (all SD cards including eMMC) which can have a TRIM command -- which however has historically been a major cause of bricks on some controller firmwares...

When I posted I was looking at some similar threads, someone made a program that deleted everything on the phone except the recovery (then you could flash another rom - I don't know if it overwrote or just deleted) I think it was for an Asus transformer tablet.
Whenever I've sold something before I have just connected it to my computer and written large files to all the available space. I don't have any sensitive data but I like to make sure everything is deleted before I sell something.
I'm surprised there's not more information/apps or whatever on this subject (wiping android) there's lots of programs for PC's to securely wipe drives. Some sites mention about encrypting the phone then wiping it, I guess that's the way to go.

My first thought was too, that it must be different from hard drives.
My initial idea would be to encrypt everything. Luckily since Honeycomb, Android supports this out of the box(but it's not hardware based) So even if data can be restored, it'd be nonsense(if the manufactorer implemented it correctly). You could choose a strong password, because you won't need to remember it anyway since you wipe the phone afterwards.
I found this article that agrees with me androidcentral.com/securely-wiping-your-android-phone-makes-it-just-fine-sell-fud
Then there is this article on lifehacker: lifehacker.com/5808280/what-should-i-do-with-my-phone-before-i-sell-it
Money quote:
Alternatively, there's the ultimate security tool if you're worried about someone pulling data from your phone: don't sell it.
Click to expand...
Click to collapse
A little off topic: Another solution would be to just store sensitive data on a SD card and remove it before selling. Plus you could use tools like EDS(Lite) to store sensitive data in container. Sync them via a cloud service and open them on your computer with TrueCrypt.

Any updates how to do this?

Boot into recovery and dd /dev/urandom over the /data, /cache and /sdcard partitions, then from the GUI reformat them...
Not perfect but well enough to prevent someone imaging from those partitions to their PC and running an undeleter (or hex editor) on the partition images!

Thanks