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.
Is there a cogent reason why the SD card cannot be partitioned without a FAT32 filesystem? From all the benchmarks I've ever seen, EXT4 kills FAT32. However, when I tried using an SD card partitioned with only an EXT4 partition, vold (the volume management daemon) wasn't happy at all.
I can manually mount the volume from the shell, but that does no good as far as android recognizing that the partition has been mounted.
I'd be willing to hack up the vold source code if it would be useful, but I just want to know if anyone has any thoughts or experience on the issue.
This question has been asked in the past, but no one has every replied to it. Is there no one with experience in this area?
Thanks
bump........
That's just what is most common and what it looks for. You could try and look at the apps2ext scripts for mounting etc.
What real performance gain could you see by using just ext4 in this scenario, my guess it nothing.
There's possibly no speed difference, though benchmarks with flash do show ext4 to be faster. The bigger point though is why have both an ext and fat partition, when you can have only one?
Also, I don't see why this should be an issue. 'mount' can auto-discover the filesystem type of a partition, so the only reason this shouldn't already "just work" is because vold is forcing it to be FAT. I find this ironic given that the main system partitions are actually YAFFS2.
I realize that there are multiple posts where this type of thing is mentioned in passing, but I wanted to ask specifically what type of SDCard is supported on the Xoom and what filesystem we should put on it.
It looks like Class 4 32GB sdcards are pretty common, but newegg also has a good price on a class 10. Which will actually work on the Xoom?
More importantly, I see all sorts of posts about sticking ext3 or ext4 on the sdcard. Sticking a journaling filesystem on flash memory doesn't seem like a wise move to me. SDCards, like all flash based memory, have a finite amount of writes available before they are toast. Journaling filesystems (such as ext3 and ext4) constantly write out their journals, which make them bad candidates for filesystems on flash memory and tend to journal the flash memory to death. Ext2, or FAT even, seem to be much better candidates -- any thoughts here?
Find help Here: http://forum.xda-developers.com/showthread.php?t=929355
This is not development. Thread moved to Q&A. Please post in the proper section next time. Thanks.
Will adding an Ext4 partition to our SD cards help with performance, and if so, do you think the benefit would be noticeable? What size partition would you recommend?
what for ? cache ?
or more room for apps ?
in any case, i doubt performance would change, at least not for the better.
Ive already got a kernel running full ext4 and its not that much faster, if at all. Partitioning your external will not increase performance at all, since your rarely reading/writing to it. Maybe a little if all your apps are on it, but even then I doubt it. I have /system/data/and /cache as ext4, and its a little faster than ext3 with a journal, but by default HTC doesn't use a journal for ext3, they use data=ordered. You can see all your filesystem options by typing in terminal emulater
su
mount
Ext2 has shown the best performance so far that I've seen while being perfectly stable.
Can somebody explain the difference between the 2 and what the advantage is for ext4? I see a new recovery tool that allows you to change this among other things. It's a nice recovery tool, but I'm not sure what the benefits are,
Generally better performance and boot times. Here's a pretty good article about EXT4:
http://linuxologist.com/1general/ext4-filesystem-explained-in-plain-english/
louslugger15 said:
Can somebody explain the difference between the 2 and what the advantage is for ext4? I see a new recovery tool that allows you to change this among other things. It's a nice recovery tool, but I'm not sure what the benefits are,
Click to expand...
Click to collapse
Pretty much nothing you'll see on an Android device. The changes are hyper tweaks that make high-end multi-user database servers, etc. run slightly faster. It does this mainly with delayed data and journal writes which can actually result in data corruption in case of sudden power loss. As far as formatting a read-only file system like the android /system partition ext4, I really don't see any point. The data partition is so rarely written to that I can't think of any reason for ext4 there either.
If you're running a RAID array of 15K SCSI fibre drives serving 10,000 customers a second, yeah, ext4 is the way to go, but using ext4 on a slow eMMC NAND drive is absurd.