Database Info

Best way to have a single app in phone memory with rest on SD?

I've had my apps on my SD card for ages now, and it works great. But, I just installed sweeter home, and while it's awesome, it is also slow as molasses in winter. I figure this is probably because it's installed to the SD card. So I want to move JUST sweeter home to the phone memory, and leave the rest of the apps on the sd.
The only way I can think of to do this tho, is to put sweeter home somewhere in /data (or elsewhere in the phone memory) and then symlink it to the app partition on the sd card. This seems rather rube goldbergian. I was wondering if anyone else could think of a better way of accomplishing the goal of one app in phone memory with the rest on the SD. I searched the forum, but didn't find any relevant posts, quite likely due to not being able to think of good search terms.

heldc said:
I've had my apps on my SD card for ages now, and it works great. But, I just installed sweeter home, and while it's awesome, it is also slow as molasses in winter. I figure this is probably because it's installed to the SD card. So I want to move JUST sweeter home to the phone memory, and leave the rest of the apps on the sd.
The only way I can think of to do this tho, is to put sweeter home somewhere in /data (or elsewhere in the phone memory) and then symlink it to the app partition on the sd card. This seems rather rube goldbergian. I was wondering if anyone else could think of a better way of accomplishing the goal of one app in phone memory with the rest on the SD. I searched the forum, but didn't find any relevant posts, quite likely due to not being able to think of good search terms.
Click to expand...
Click to collapse
if i had to guess copy it into system/app

duh, of course. Thanks!
Edit-Sadly, copying it into /system/app didn't work. Neither did leaving the actual file in /system/app and symlinking it to /data/app-private. Ah well.

i could also benefit from this if it can be done

If I get it to work, I'll let you know. I tried copying it BACK from /system/app to /data/app-private, and it STILL didn't work. Ultimately, I had to reinstall it.

rm the symbolic link just for that app??

Apps aren't actually run from /data/app, its run from the dalvik cache directory which means ahome's slowness isn't due to apps on sdcard.
Try dxtop its quite fast.

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.

Using a swap file in /data partition?

Hey guys!
Just been racking my brains for ways to try and speed up my poor little G1, as its quite a sloth these days In my quest for more memory, I have tried using swap on my SD card, and despite having a Sandisk Ultra, it does (overall!) seem to make my phone much slower, I also tried compcache (still slow) and compcache with backing swap (slow again). It does have some benefits I have noticed, but overall not, so I turned it all off.
I was thinking about the different partitions in the phone, and I'm assuming that the /data partition is probably faster than an SD card, I could be wrong. So I was thinking, why not put a swap file on the much lesser used (got apps2sd) /data partition in the hope that it wont be as painfully slow and supply some better swap? I used DroidSwap to set the location of the test 16MB file on the data partition, told it to go ahead. It created it, did a mkswap on it, then for whatever reason couldn't swapon on it. I then tried a mkswap on the file manually in terminal, worked fine, then swapon, get an 'invalid argument' error. Tried to google it, and I didn't really find anything of use. I'm running the one just before the latest Cynanogenmod. Can anyone give me some insight, or tell me if I'm just on a wild goose chase and wasting my time?
Thanks in advance!
Chris

I think it will be something to do with the filesystem
I may be wrong, but I think yaffs are 'fractured' and therefore no good for what you want
In anycase it probably isn't a good idea to hammer out with swap you only get so many read writes , and it is much easier to replace an sdcard.
there is an app called auto memory on the market, you may be able to get some use out of that.
when it comes to swap there is always some debate about what's best
some, none, lots, etc
personally I'm in the “lots as soon as possible“ camp
I would rather have real memory available to my current app than having some app I'm not using hog it. having a lil bit of lag while pages load back from swap is better than waiting for a killed app to reload, which is what happens when you have no swap and lots of apps
but at the end of the day no one is wrong, all options have pros and cons.
all very much depends on your usage.

[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.

Directories disappearing from "sdcard"

Anyone having issues with whole directories becoming corrupted or even disappearing from your storage?
EDIT: Just noticed my LOST.DIR directory is 1.16GB! Every time I reboot, there are dozens of files in LOST.DIR again. Should I format my sdcard storage, or is this thing rapidly becoming trashed?

el_smurfo said:
Anyone having issues with whole directories becoming corrupted or even disappearing from your storage?
EDIT: Just noticed my LOST.DIR directory is 1.16GB! Every time I reboot, there are dozens of files in LOST.DIR again. Should I format my sdcard storage, or is this thing rapidly becoming trashed?
Click to expand...
Click to collapse
Just a bump and plea for folks to check their own SD for LOST.DIR. I often find on a reboot that entire clockwork backups, directories of ringtones, etc are missing and LOST.DIR is huge with files. I am carefully mounting and unmounting my storage when connected to PC, but copying files back and forth seems to be the problem.

Thanks for tip
More than a few have this issue--me included
Don't know if it is kernel related
I will soon try LeeDroid if problem persists, which is 1.78 EU. It was last Rom I ran with zero issues, buy wanted the TMO US one when it came out. All the roms run great barring this sdcard issue.
If I do and it works will post--I have a thread in Q&A on it also--

I do have a LOST.DIR, nothing in it yet though.
Might be similar to the LOST+FOUND dir on Linux where stuff found during a fsck after a crash or unclean unmount of a drive end up, http://tldp.org/LDP/Linux-Filesystem-Hierarchy/html/lostfound.html
Here is an xda thread on your problem, seems decently well researched: http://forum.xda-developers.com/showthread.php?t=1075910

frdd said:
I do have a LOST.DIR, nothing in it yet though.
Might be similar to the LOST+FOUND dir on Linux where stuff found during a fsck after a crash or unclean unmount of a drive end up, http://tldp.org/LDP/Linux-Filesystem-Hierarchy/html/lostfound.html
Here is an xda thread on your problem, seems decently well researched: http://forum.xda-developers.com/showthread.php?t=1075910
Click to expand...
Click to collapse
Yup, that's the problem. Since he was complaining about Froyo, I'm guessing it's not a software problem and is actually a bad "sdcard". I've gotten so used to having files corrupted, I pretty much store everything on cloud services now, so I guess it's training me for the future.