Related
Hi
I bought a kingston 512mb sd, but my xdaII is reporting it as a 483,55 mb size...
I already tried to format it with FAT32 but didn't solve it
any idea ?
thanks!
Memory
I ain't no IT guru but this much I know.
There's this memory mystery which has been around that I tried reading about before however after attempting to digest the article I'd rather it remained a mystery.
:mrgreen:
It's normal Bro. Hopefully some expert will provide a proper explanation for you. In the mean time I hope you can take my word for it.
Here's a screenshot of my 512MB SD card memory.
The main reason for the difference in size is this, even though your SD is a "memory" card, your PPC treats it like a disk drive - you format it with a FAT file system.
FAT stands for File Allocation Table, meaning that there is a table stored on the media (just like on a hard drive or floppy drive) that stores the location of the files on the media so they can be located quickly and easily, since files are not stored contiguously. Think of it as an index.
The larger the media, the larger the FAT. For instance, the following are my SD cards and their FAT sizes: 128MB/8MB; 256MB/16MB; 512MB/32MB; 1GB/58MB.
HTH
argh
:shock:
How didn't remember that ? :roll:
You know, the card was so much expensive than i wanted to pay, that when i tested it, i just felt reaaaaallly mad!
(i was just thinking how much does 29mb cost!)
thanks for the replys and fast help!
Actually, there was a patch, that allowed to use the space, that is not physically taken by FAT32: FAT32 reserves 32b for each possible catalog. If your catalogs are only, for instance, 12b long - you don't need resting 20b, but it's reserved by FAT, so you can't store anything there! The bigger storage you have, the more it reserves! The patch allowes you use the spase unless it's physically taken.
I'll try to find the patch till the end of the week and post it.
PS: you can also format your card in FAT16 or even FAT8 - both will take less space!
big fat making diet
that would be great! thanks!
Oops
Oops!
So the memory mystery don't apply in this huh?
Sorry hbatista for giving wrong info.
Thanks guys for the enlightenment.
The other reason is some retailers claim 512 megabytes, however their megabyte is 1000kb whereas we are used to the idea that a megabyte is 1024kb.
Kignston explanation
Hi
Before i posted to this forum i contacted kigston and here their explanation:
"Dear Mr. Batista,
Regarding your below request:
The fact that your flashcard shows about 6% less of its capacity is quite normal and the following will try to explain why:
When formatted to a specific file system, storage devices such as the Kingston flash card SD/512 "loose" a small amount of capacity because this is used by the file system to store file system information. Operating systems (such as Windows, for instance) will format using 1K=1024 bytes rather than 1K=1000 bytes resulting in some residual loss of capacity.
SD technology comes with a security feature that enables manufacturers to add specific hardware controlled security features for their software when stored on an SD card. More information regarding this can be obtained from the SDA (Secure Digital Association) at http://www.sdcard.org. Furthermore a so-called "OS overhead" exists, where the operation system stores OS specific data on the storage device. The overhead varies between different OS.
An overall overhead of 29MB is well within limits and you will find that it will be the normal amount of overhead for the SD/512 for your OS.
You can observe the same effect for all your other storage devices, especially hard drives.
Usually the reduction of available data is in the range of 2%-7%. You can try and replace the card at your point of purchase, if you feel that the problem is related to a defect of the card rather than the above phenomenon, however it is most likely that the replacement will show the same capacity.
Regards"
Click to expand...
Click to collapse
Hi, I've searched the forum but found no answer. Searched google and found contradictory answers.
Should I use a swap file in SD card?
What are the advantages and disadvantages?
Thanks
brk said:
Hi, I've searched the forum but found no answer. Searched google and found contradictory answers.
Should I use a swap file in SD card?
What are the advantages and disadvantages?
Thanks
Click to expand...
Click to collapse
Advantage: Allows more multitasking due to more memory use from the sd card.
Disadvantage: Shortens the sd card life.
If you plan to use swap or A2SD, I recommend getting a class 6 sd card. Some people are opposed to swap, some people are all up for it. It's just up to your preference. For me, swap is just nice that an app doesn't close when I'm using another app.
koreancanuck said:
Advantage: Allows more multitasking due to more memory use from the sd card.
Disadvantage: Shortens the sd card life.
If you plan to use swap or A2SD, I recommend getting a class 6 sd card. Some people are opposed to swap, some people are all up for it. It's just up to your preference. For me, swap is just nice that an app doesn't close when I'm using another app.
Click to expand...
Click to collapse
A good answer but slightly incomplete. Most sdcards have wear leveling so having swap on your card will do very minimal damage.
brk said:
Hi, I've searched the forum but found no answer. Searched google and found contradictory answers.
Should I use a swap file in SD card?
What are the advantages and disadvantages?
Thanks
Click to expand...
Click to collapse
If you want to have a swap file (swap.swp) this could possibly corrupt your fat partition. This is based on my own personal experience of course. I recommend use a swap partition honestly.
Just imagine mounting your sdcard to your computer to transfer files while your phone is still attempting to write to /sdcard/swap.swp. This can theoritically cause problems. And you don't want problems on your sdcard. A seperate partition is the safest way to go. But again... just my opinion.
Note that if you are using a rom based on Cyanogen's kernel (such as 5.0.7 or 5.0.8) it is NOT recommended to use swap at all. It will slow down your phone causing more problems than what it's worth. ('Swap grave' is how he put it.)
Binary100100 said:
If you want to have a swap file (swap.swp) this could possibly corrupt your fat partition.
Click to expand...
Click to collapse
How does that happen?
endolith said:
How does that happen?
Click to expand...
Click to collapse
If your system is writing to the .swp while you mount/unmount the sdcard it can corrupt the card. It's better to use the partition.
In addition if your system is setup to use the swap.swp on your fat32 partition and you mount it to your computer, what do you suppose would happen to your system since it can no longer have access to the .swp file?
Again... not a good idea.
I don't see how unmounting the swap partition is any different from unmounting the partition with a swap file on it.
Just say no!
endolith said:
I don't see how unmounting the swap partition is any different from unmounting the partition with a swap file on it.
Click to expand...
Click to collapse
Right, but other than when you shut down your phone, when does your swap partition get [un]mounted?
AdrianK said:
Right, but other than when you shut down your phone, when does your swap partition get [un]mounted?
Click to expand...
Click to collapse
When you plug it into a computer, isn't the whole SD card mounted?
endolith said:
When you plug it into a computer, isn't the whole SD card mounted?
Click to expand...
Click to collapse
Your computer's OS can only mount the filesystems it supports, for example OOTB Windows only supports FAT and NTFS, so it can't do anything with ext. Anyway, linux-swap is non-persistant, you can't mount it to view the contents, my understanding is that should you mount it on linux, the swap partition will be ignored.
AdrianK said:
Your computer's OS can only mount the filesystems it supports, for example OOTB Windows only supports FAT and NTFS, so it can't do anything with ext.
Click to expand...
Click to collapse
But the point is that they're all unmounted before the SD card can be shared with the computer as a mass storage device, so I don't see there being any difference between a swap partition and a swap file.
Besides, Swapper has a default "safe" option that unmounts swap before sharing SD with the computer and remounts it after disconnecting.
endolith said:
But the point is that they're all unmounted before the SD card can be shared with the computer as a mass storage device, so I don't see there being any difference between a swap partition and a swap file.
Besides, Swapper has a default "safe" option that unmounts swap before sharing SD with the computer and remounts it after disconnecting.
Click to expand...
Click to collapse
I wasn't aware that Swapper has such a feature but that doesn't change the fact that if your running say ~200mb of RAM with ~64mb of swap and with all the multitasking that you're doing you're using up most of it... so say you have only ~10mb free. Then all of a sudden you pull out your sdcard. What do you think happen will happen? Your phone was reading and writing to that card! Do you think that's healthy? If Swapper unmounts it before it shares the sdcard with the computer then it may be better for the sdcard but I don't see how that can have a positive impact on the device. However if you have swap on a seperate partition the only way to run into this problem would be to remove the card from the device. Even if you mount the sdcard to the computer the phone still has access to the swap partition just like it still has access to the ext partition (if it has one).
I don't know about you but I have a 16gb class 6 card and it's a pain in the butt to restore my data to the fat partition so I would rather not have anything read/write to it unless necessary and to have something constantly reading and writing to it is a really bad idea in my case... but maybe you have a ~2gb and reloading the data may not be annoying to you.
Anyway... stick with what works. I've tried them all and based on my own experience I suggest the separate partition if you are going to use swap. But hey... what do I know?
By the way... do NOT use swap on CM5 or CM6. It may help at first but you'll be enroute to digging "a swap grave" (quoted by Cyanogen himself).
Your phone will ONLY share FAT when mounted to PC
Ext and Swap are still running on the phone(app2sd how do you think apps keep working after mounting?)
Same deal with Swap...
I personally do not use Swap although i do have a 128mb Swap Partition.
Binary100100 said:
I wasn't aware that Swapper has such a feature but that doesn't change the fact that if your running say ~200mb of RAM with ~64mb of swap and with all the multitasking that you're doing you're using up most of it... so say you have only ~10mb free. Then all of a sudden you pull out your sdcard. What do you think happen will happen?
Click to expand...
Click to collapse
Android routinely kills processes as part of its "task management", and the apps are expected to save their state using "Bundles" so that when you restart them, they restart in the same state they were last in. Is unplugging the swap more harsh than killing the app?
Once Android determines that it needs to remove a process, it does this brutally, simply force-killing it. The kernel can then immediately reclaim all resources needed by the process, without relying on that application being well written and responsive to a polite request to exit. Allowing the kernel to immediately reclaim application resources makes it a lot easier to avoid serious out of memory situations.
Click to expand...
Click to collapse
Even if you mount the sdcard to the computer the phone still has access to the swap partition just like it still has access to the ext partition (if it has one).
Click to expand...
Click to collapse
Hmmm. When you mount the SD card, the entire SD card is available on the computer, including the FAT, EXT, and swap partitions, but the phone can't access the FAT partition?
I can see the contents of the swap partition from the computer with "sudo cat /dev/sdb3", but the phone can still access it? If I run "free" on the phone, it still shows swap, and the used size still changes, so I guess the phone is still using it, but the computer can see it at the same time, too.
In that case, I understand why it would make more sense to use swap partition than swap file.
I don't know about you but I have a 16gb class 6 card and it's a pain in the butt to restore my data to the fat partition so I would rather not have anything read/write to it unless necessary and to have something constantly reading and writing to it is a really bad idea in my case... but maybe you have a ~2gb and reloading the data may not be annoying to you.
Click to expand...
Click to collapse
I have an 8 GB Class 6 and I don't understand what you're talking about. What do you mean "restore your data to the fat partition"? Restore it from what? What's the point of having an SD card if you don't want anything reading from it?
Anyway... stick with what works.
Click to expand...
Click to collapse
By the way... do NOT use swap on CM5 or CM6. It may help at first but you'll be enroute to digging "a swap grave" (quoted by Cyanogen himself).
Click to expand...
Click to collapse
What does that mean? Where did he say that? In what context?
I'm using swapper with CM5, and it's like buying a new phone. It greatly speeds up the phone's responsiveness.
I dunno why you can see all three partitions. When I've got my swap and extra partitions setup and mount my SD to my computer, the only partition that shows up is the FAT one, using Windows that is.
As for using swap, a quick Google search will show you a number of threads stating that the only time you see a real benefit from it is on the G1 an older mytouchs with the lower RAM space. Actually most say that using compcache is the better way to go if you've got the extra RAM space.
Sent from my HTC Magic using XDA App
endolith said:
What does that mean? Where did he say that? In what context?
I'm using swapper with CM5, and it's like buying a new phone. It greatly speeds up the phone's responsiveness.
Click to expand...
Click to collapse
I guess nobody listens to the people that know what they are talking about. Then they always complain when it doesn't work properly. #Ironic
http://twitter.com/cyanogen/status/13986716217
http://twitter.com/cyanogen/status/13624854797
http://twitter.com/cyanogen/status/13980541397
http://twitter.com/cyanogen/status/13980541397
http://twitter.com/cyanogen/status/13979643918
Enough for you?
And I'm aware that 2.2 automatically kills idle apps, which is all the more reason that you do not need swap.
And your phone cannot access the /sdcard or /mnt/sdcard partition while it is connected to your computer as removable storage. Try it.
Try downloading something to your sdcard while it's connected as removable storage. You can't. Your phone does not have access to the sdcard. In fact... while it's mounted to your computer go to settings SD card & phone storage settings and tell me what it says under Total space and Available space.
Do NOT use a large .swp file because your phone is constantly writing to the sdcard! All it takes is a single instance of removing it without unmounting it and you will have corrupted the entire contents of the fat partition. That is what I mean by restoring the data on the sdcard. I use an ADATA 16gb class 6 sdcard and each time that I tried with the .swp file I ended up losing my data because of random kernel crashes, dead battery, unsafe sdcard mounting etc.
But if you are really convinced of otherwise then go on ahead but I'll tell you right now, I will refuse to help anyone that never listened to my advice the first time. If I give a warning and if someone doesn't listen then it's all on them. I will personally refuse to help them and I wouldn't blame anyone for doing the same. Cyanogen warned users not to use swap. So those that have issues shouldn't complain to him or anyone else because it's their own fault.
All quotes from Cyanogen on twitter. You should follow him and learn something.
@w3stbr00k I don't know.. none of my roms have swap support built in. You would have had to do it yourself.
Click to expand...
Click to collapse
@misscocogold t3 is otw in an hour or so. Make sure you aren't using swap or task killers too.
Click to expand...
Click to collapse
@singharvinder the new code actually uses swap more aggressively as a side effect
Click to expand...
Click to collapse
@singharvinder are you using swap? Don't.
Click to expand...
Click to collapse
DonJuan692006 said:
I dunno why you can see all three partitions. When I've got my swap and extra partitions setup and mount my SD to my computer, the only partition that shows up is the FAT one.
As for using swap, a quick Google search will show you a number of threads stating that the only time you see a real benefit from it is on the G1 an older mytouchs with the lower RAM space. Actually most say that using compcache is the better way to go if you've got the extra RAM space.
Sent from my HTC Magic using XDA App
Click to expand...
Click to collapse
You can actually access the swap partition from a Linux based OS such as Ubuntu/Live CD.
When you mount the sdcard you also have access to the ext2,3,4 partition if it's available.
See what I get for being Windows exclusive? Edited my first post to be more precise with my wording.
DonJuan692006 said:
I dunno why you can see all three partitions. When I've got my swap and extra partitions setup and mount my SD to my computer, the only partition that shows up is the FAT one.
Click to expand...
Click to collapse
In Linux, both the SD and EXT partitions are mounted, but I can see and access all three. I can see all three partitions in Windows 7 Disk Management, too, but of course Windows can only mount the FAT partition.
a number of threads stating that the only time you see a real benefit from it is on the G1
Click to expand...
Click to collapse
I've got a G1.
Binary100100 said:
I guess nobody listens to the people that know what they are talking about. Then they always complain when it doesn't work properly. #Ironic
Click to expand...
Click to collapse
I'm looking for truth, not rumor. I'm not going to blindly accept statements made without explanation.
Enough for you?
Click to expand...
Click to collapse
Nope. I want to understand why it's a bad idea. Twitter posts aren't exactly comprehensive.
http://twitter.com/cyanogen/status/13986716217
Click to expand...
Click to collapse
This is not a recommendation against swap. Someone was talking about disabling swap, and he said it's not his problem because CM doesn't come with swap enabled.
http://twitter.com/cyanogen/status/13624854797
Click to expand...
Click to collapse
I read this as "If you're having problems with apps closing, disable swap and task managers. Maybe you have those configured wrong." That doesn't mean swap is inherently harmful.
http://twitter.com/cyanogen/status/13980541397
http://twitter.com/cyanogen/status/13979643918
Click to expand...
Click to collapse
This thread is about speed and performance, not harm.
And I'm aware that 2.2 automatically kills idle apps, which is all the more reason that you do not need swap.
Click to expand...
Click to collapse
Yes, this is the standard response in threads like this. "Android automatically manages tasks and memory, so you shouldn't try to second-guess it". But, empirically, swap makes the phone run better and faster.
If you switch to another app from the browser, for instance, the browser almost always gets killed, and then it has to reload the entire page from the Internet when you switch back to it. This takes wayyyy longer than reloading the state from swap, and causes problems when the web page is dynamic.
Many apps take much longer to start up than they should, or don't actually return to the same state when they're restarted, and swapping them out works better. I'm guessing the people who are happy with the stock system use their phones differently.
And your phone cannot access the /sdcard or /mnt/sdcard partition while it is connected to your computer as removable storage.
Click to expand...
Click to collapse
Yes, I already agreed with that. Swap file is a bad idea since it's inaccessible when you mount on the computer, but swap partition still is. Agreed.
endolith said:
In Linux, both the SD and EXT partitions are mounted, but I can see and access all three. I can see all three partitions in Windows 7 Disk Management, too, but of course Windows can only mount the FAT partition.
I've got a G1.
I'm looking for truth, not rumor. I'm not going to blindly accept statements made without explanation.
Nope. I want to understand why it's a bad idea. Twitter posts aren't exactly comprehensive.
This is not a recommendation against swap. Someone was talking about disabling swap, and he said it's not his problem because CM doesn't come with swap enabled.
I read this as "If you're having problems with apps closing, disable swap and task managers. Maybe you have those configured wrong." That doesn't mean swap is inherently harmful.
This thread is about speed and performance, not harm.
Yes, this is the standard response in threads like this. "Android automatically manages tasks and memory, so you shouldn't try to second-guess it". But, empirically, swap makes the phone run better and faster.
If you switch to another app from the browser, for instance, the browser almost always gets killed, and then it has to reload the entire page from the Internet when you switch back to it. This takes wayyyy longer than reloading the state from swap, and causes problems when the web page is dynamic.
Many apps take much longer to start up than they should, or don't actually return to the same state when they're restarted, and swapping them out works better. I'm guessing the people who are happy with the stock system use their phones differently.
Yes, I already agreed with that. Swap file is a bad idea since it's inaccessible when you mount on the computer, but swap partition still is. Agreed.
Click to expand...
Click to collapse
Well it sounds like you have answered the threads questions then. An expert such as yourself should have come along a while ago and stated this for the community. Now that you have discredited Cyanogen and all the other Senior Members and developers maybe I'll just direct all of my private messages regarding swap, compcache and userinit.sh scripts to you. Enjoy it!
Can someone explain to me what is inside the vibrant that is used as storage.
People refer to the internal memory card, why, is it an actual memory card or is it simply because apps cannot be stored there.
Why is the app storage space limited to 2gb if the internal memory is 16gb, and if all 16gb resides on the same medium can't it just be symlinked similar to what people do with apps2sd on other phones with no detriment in performance?
Calcvictim said:
Can someone explain to me what is inside the vibrant that is used as storage.
People refer to the internal memory card, why, is it an actual memory card or is it simply because apps cannot be stored there.
Why is the app storage space limited to 2gb if the internal memory is 16gb, and if all 16gb resides on the same medium can't it just be symlinked similar to what people do with apps2sd on other phones with no detriment in performance?
Click to expand...
Click to collapse
There are 2 storage types soldered onto the vibrant. NAND (fast, small) and "flash" (16g, slow).
The nand is split up for various things like booting, firmware (/system), cache, etc. And - to solve lag with their own apps - 128 megs of it is split out for the built-in apps to use. (That is the 'method 1' fix - move all app data to nand, where it is super fast.)
The 16 gigs of flash is much slower than nand, and split into 2 sections:
- /data (mmcblk0p1) is android apps, app storage, settings, etc. (2 gigs of "application space"). This is the standard android-phone onboard storage, and not accessible to the PC.
- /sdcard (mmcblk0p2) is the 14 gig media/misc space. Standard fat filesystem, shown when you plug into the PC. (They basically subverted the standard android sdcard handling for this - solves some problems, but causes others.)
The removable sd is mounted to "/sdcard/sd".
^ awesome post man, care if I stick it in the sticky?
Disconn3ct said:
There are 2 storage types soldered onto the vibrant. NAND (fast, small) and "flash" (16g, slow).
The nand is split up for various things like booting, etc. And - to solve lag with their own apps - 128 megs of it is split out for the built-in apps to use. (That is the 'method 1' fix - move all apps to nand, where it is super fast.)
The flash is much slower than nand, and split into 2 sections:
- /data is android apps, app storage, settings, etc. (2 gigs of "application space"). This is the standard android-phone onboard storage, and not accessible to the PC.
- /sdcard is the large media/misc space. Standard fat filesystem, shown when you plug into the PC. (They basically subverted the standard android sdcard handling for this - solves some problems, but causes others.)
The removable sd is mounted to "/sdcard/sd".
Click to expand...
Click to collapse
so RyanZA's lag fix, which creates a 1gb file system within the 2 gigs....why can't it be mapped outside of the original appspace since everything resides on flash anyway, the speeds should be the same, no?
s15274n said:
^ awesome post man, care if I stick it in the sticky?
Click to expand...
Click to collapse
Sure. (I wanted to doublecheck some info, so it is slightly updated.)
Calcvictim said:
so RyanZA's lag fix, which creates a 1gb file system within the 2 gigs....why can't it be mapped outside of the original appspace since everything resides on flash anyway, the speeds should be the same, no?
Click to expand...
Click to collapse
"mapped outside the original appspace"? Those words all make sense but not in that order
Data (and cache and so forth) all use samsung's proprietary RFS filesystem. (It has been described as "fat with wear levelling, unix perms and journalling".) The loopback mount fix basically bypasses all that and just shows rfs a large monolithic file. You lose reliability (journal) and flash protection (wear levelling, erase optimization) and so forth, but get speeds much closer to the raw flash. (Personally, I'm a fan of not prematurely destroying soldered on storage..)
One of the things to be tried is yaffs/jffs in place of rfs - all the advantages/protections with much better performance..
Disconn3ct said:
"mapped outside the original appspace"? Those words all make sense but not in that order
Click to expand...
Click to collapse
I understand about the RFS, I just don't really understand why the appspace is limited to 2 gigs when there are 16 gigs on the same piece of silicon. Why is it not a matter of partitioning and mounting the other 16 gigs?
Calcvictim said:
I understand about the RFS, I just don't really understand why the appspace is limited to 2 gigs when there are 16 gigs on the same piece of silicon. Why is it not a matter of partitioning and mounting the other 16 gigs?
Click to expand...
Click to collapse
First, it's not "the other 16 gigs". It is 16 gigs total - 2 for apps/data, 14 for media/etc.
How pissed would you be if only kies (and adb) could get to that storage? That's why - 14 of it is presented as vfat, so that it can be exported over usb to the pc. You might be able to adjust the split a little (eg 8/8) using modified pit files and odin, but I wouldn't even count on that..
Certainly you can't share the space - android security guarantees that only the app (well, and root, but..) can read the app's files. Not the pc, not other apps. So you need something vfat hasn't got (owners, permissions) and you need to not export it to the pc where those limits won't be enforced. (Finally, you only get one fs user at a time - if you have it on the pc, you can't have it on the phone. "Please reboot into usb mode" hasn't been OK since the late 90s...)
Disconn3ct said:
First, it's not "the other 16 gigs". It is 16 gigs total - 2 for apps/data, 14 for media/etc.
How pissed would you be if only kies (and adb) could get to that storage? That's why - 14 of it is presented as vfat, so that it can be exported over usb to the pc. You might be able to adjust the split a little (eg 8/8) using modified pit files and odin, but I wouldn't even count on that..
Certainly you can't share the space - android security guarantees that only the app (well, and root, but..) can read the app's files. Not the pc, not other apps. So you need something vfat hasn't got (owners, permissions) and you need to not export it to the pc where those limits won't be enforced. (Finally, you only get one fs user at a time - if you have it on the pc, you can't have it on the phone. "Please reboot into usb mode" hasn't been OK since the late 90s...)
Click to expand...
Click to collapse
Ok, so if someone did modify the PIT file then it would be possible. It's not a hardware limitation, but just the way the firmware is setup.
What speed is the other 14Gb? How does it compare to standard microSD? Class 4 at least?
Calcvictim said:
Ok, so if someone did modify the PIT file then it would be possible. It's not a hardware limitation, but just the way the firmware is setup.
Click to expand...
Click to collapse
Modify the pit, and the bootloader, and (possibly) the rfs partition scheme, and (possibly) the kernel.
People found a pit that changes the layout a little bit and they're getting a higher-than-normal percentage of bricks. (I don't know how high, but look at all the odin threads that warn against using the new pit..) It is doable, but not reliable yet. Did you already fill 2 gigs of app storage? Thats .. kinda nuts.
applebook said:
What speed is the other 14Gb? How does it compare to standard microSD? Class 4 at least?
Click to expand...
Click to collapse
They claim class 6. With rfs, it is ok until you get to multiple requests - then it goes all thrashy instead of threading properly..
If it's around class 6, then I'm satisfied. Since that memory is for storing media, I have little use for anything much faster anyway.
Disconn3ct said:
People found a pit that changes the layout a little bit and they're getting a higher-than-normal percentage of bricks. (I don't know how high, but look at all the odin threads that warn against using the new pit..) It is doable, but not reliable yet. Did you already fill 2 gigs of app storage? Thats .. kinda nuts.
.
Click to expand...
Click to collapse
I didn't fill the 2 gigs but I don't use the phone for media really, it's just apps and games and just wandering since it would be nice to have more storage for those things.
So what is the size difference between the Vibrants with the larger NAND and the smaller NAND?
What difference does this make in the real world?
Why would they put two different size NAND chips?
SamsungVibrant said:
Why would they put two different size NAND chips?
Click to expand...
Click to collapse
Samsung does some weird things sometimes
Disconn3ct said:
"mapped outside the original appspace"? Those words all make sense but not in that order
Data (and cache and so forth) all use samsung's proprietary RFS filesystem. (It has been described as "fat with wear levelling, unix perms and journalling".) The loopback mount fix basically bypasses all that and just shows rfs a large monolithic file. You lose reliability (journal) and flash protection (wear levelling, erase optimization) and so forth, but get speeds much closer to the raw flash. (Personally, I'm a fan of not prematurely destroying soldered on storage..)
One of the things to be tried is yaffs/jffs in place of rfs - all the advantages/protections with much better performance..
Click to expand...
Click to collapse
So are you saying that samsung's filesystem (rfs) causes wear and tear to the flash drive? Do any of the lag fixes that replace the rfs filesystem (ext 2/3/4) cause wear and tear to the drive as well? I am personally not applying a lag fix for this reason, but if samsung's rfs does that already, might as well take the plunge with a lag fix...
I read somewhere that the nexus one uses a filesystem created for flash drives - it started with a y, probably the yaffs that you spoke of?
Sent from my SGH-T959 using XDA App
veol said:
So are you saying that samsung's filesystem (rfs) causes wear and tear to the flash drive? Do any of the lag fixes that replace the rfs filesystem (ext 2/3/4) cause wear and tear to the drive as well? I am personally not applying a lag fix for this reason, but if samsung's rfs does that already, might as well take the plunge with a lag fix...
I read somewhere that the nexus one uses a filesystem created for flash drives - it started with a y, probably the yaffs that you spoke of?
Sent from my SGH-T959 using XDA App
Click to expand...
Click to collapse
I took him to mean that a loopback mount style lagfix, like OCLF, can cause premature deterioration.
Kubernetes said:
I took him to mean that a loopback mount style lagfix, like OCLF, can cause premature deterioration.
Click to expand...
Click to collapse
That all depends on how samsung implemented wear leveling. It would be insanely stupid to do it in a way that would cause premature death of the flash with a loop file system though. Wear leveling is generally done at the block level so that file systems that have to write to fixed locations a lot like fat don't kill that block. As rfs is fat, I think it's unlikely that it will cause issues.
We can't use yaffs2 and friends without replacing the kernel driver for the flash. They don't work on block devices, they require raw flash access. I suspect it will also require a new secondary boot loader. I wouldn't attempt it without a dev phone and jtag access.
ttabbal said:
That all depends on how samsung implemented wear leveling. It would be insanely stupid to do it in a way that would cause premature death of the flash with a loop file system though. Wear leveling is generally done at the block level so that file systems that have to write to fixed locations a lot like fat don't kill that block. As rfs is fat, I think it's unlikely that it will cause issues.
We can't use yaffs2 and friends without replacing the kernel driver for the flash. They don't work on block devices, they require raw flash access. I suspect it will also require a new secondary boot loader. I wouldn't attempt it without a dev phone and jtag access.
Click to expand...
Click to collapse
Ah... sorry for asking a noobish question and being off-topic a little, but if I were to use a lagfix, which one is best (for the flash drive)?
Thanks for the questions and the answers and for laying it out in understandable terms! A good read.
Sent from my SGH-T959 using XDA App
It is by now well known the SGS has a lag issue (apps slow to launch, email slow to access, etc) that can be fixed by changing filesystems for parts of the device, to make it blazingly smooth.
There are several fixes available, some based on SD card, some used through PC, some based on kernel flashing, some based on on-device apps, etc.
At the time of this writing it is hard to say which is better. I would personally advise you to take a quick look around at which fixes are available.
Most of them are listed/referenced from the FAQ thread here: http://forum.xda-developers.com/showthread.php?t=723596
--
This is a placeholder post, the first method was stickied before but this seemed unfair to the other methods and may not be the method most suited to your device usage and situation. At this time, all of the fixes have their specific quirks and needs. Hopefully soon we will see a "much better than all the rest" fix soon from one of the devs here, or Samsung might even fix it themselves
If someone cares to write down a comparison between all the available methods at this time, feel free to post it in a reply here!
Great idea Chainfire.
When a user first decided to use a modified/custom/different firmware on their Samsung Galaxy S, they usually go through these steps:
1. Flash with Odin/Kies
2. Flash update.zip for root
3. Flash other update.zip (GPS fix, battery mod, etc) as necessary
4. Do a lag fix.
It took me a few hours and reading through countless posts to see the pro's and con's for each lag fix.
I will try to go through them as succintly as possible, and if anyone needs more explanation you can either click the link or do a search.
Feel free to correct me, this is how I see the lagfix as when I applied and tested it
Before starting, here is the internal structure of non volatile memory (where data persist after reboots) in Samsung Galaxy S:
- 128MB of very fast NAND (some people incorrectly called this ROM)
- 16/8GB of internal SD with 2GB set aside for application installs (this is why you see your internal SD as either 13+ or 5+ remaining, the 2GB shows up as Internal Phone storage)
- your micro SD card (external SD)
The lag is due to the inefficiency of the file system used in the 2GB (/data) partition for applications, stalling a lot of the read/write operation. You can search this for further reading if you want to.
Lag fixes
- MoDaCo's lagfix: Better than stock on old F/Ws but about the same as JM1/2/5 and JP1/2/3
This lagfix uses the 128MB very fast NAND to store your applications instead.
Pro: very very fast applications opening/switching performance
Cons: You are limited to 128MB of apps including built in apps .
- Mimocan's lagfix: Significant improvements in performance which can also be benchmarked. Requires an external SDcard formatted partly in fat and partly ext3 or ext4.
This moves the /data files into the ext3/ext4 partition on an external microSD card
Pros: very fast, lots of storage space for apps
Cons: You will be unable to unmount your external SD card when the phone is on, and you need an external SD card for this to work
- OneClick Lagfix by RyanZA: Based on mimocan but using the internal SD card. Results are better than with basic mimocan and it is a lot easier to install.
This creates a file inside the 2GB partition that is mounted as /data.
Pros: very fast, lots of storage space for apps, easy to install and undo, available in the market.
Cons: if you install too many apps you won't be able to roll back the lag fix unless you delete some apps. Superseded by RyanZA lag fix 2.3 beta
Erroneous free space on Internal Phone storage (/data)
There are still stalls when installing apps, and when accessing android applications database
- CFLagFix by Chainfire: Based on mimocan, approximately the same as RyanZA's fix.
pretty much the same as OneClick Lagfix.
look above for Pros
Cons: There are still stalls when installing apps, and when accessing android applications database
-Voodoo lag fix by supercurio: a new class of total lag fix
Instead of creating a file inside the rfs partition and mounting it as /data/data, the voodoo lag fix updates the kernel so that the the 2GB partition is using ext4 instead or rfs. This gives the best possible lag fix.
Pros: fast, smooth, across everything you do. The way galaxy s should have been in the first place. The best and most consistent lag fix with no remaining lag left that is caused by rfs.
Support with other kernel mods are starting to show: backlight mod, OC/UV kernel
Cons: Incompatible with clockworkmod recovery
I am now using voodoo lagfix beta 4 only
http://project-voodoo.org/
I hope this helps
So, I usually read a lot on the Android Dev side of the SGS since I am very keen on a fix that will eliminate the lagging issues on the phone. I was in Spain for a holiday at the end of August and have come home to find a new 'Project Voodoo' fix being touted around. What sort of method does this fix entail?
And does anyone out there in the developer community believe that there will be a fix that will reformat the entire 2gb data partition to YAFFS2/EXT4/NILFS2 etc, as opposed to mounting a virtual file system on top of RFS? Or is it possible that Samsung themselves could remedy this with the 2.2 update?
sionyboy said:
And does anyone out there in the developer community believe that there will be a fix that will reformat the entire 2gb data partition to YAFFS2/EXT4/NILFS2 etc, as opposed to mounting a virtual file system on top of RFS? Or is it possible that Samsung themselves could remedy this with the 2.2 update?
Click to expand...
Click to collapse
Voodoo does that - ie mount /data as ext4
een625 said:
- OneClick Lagfix by RyanZA: Based on mimocan but using the internal SD card. Results are better than with basic mimocan and it is a lot easier to install.
This creates a file inside the 2GB partition that is mounted as /data.
Pros: very fast, lots of storage space for apps, easy to install and undo, available in the market.
Cons: if you install too many apps you won't be able to roll back the lag fix unless you delete some apps. Superseded by RyanZA lag fix 2.3 beta
Erroneous free space on Internal Phone storage (/data)
- CFLagFix by Chainfire: Based on mimocan, approximately the same as RyanZA's fix.
pretty much the same as OneClick Lagfix.
look above for Pros
Cons: unable to rollback changes
Click to expand...
Click to collapse
RyanZA - good, but slower than minocans when you have a lot of apps/use phone for a few days.
CFLagFix by Chainfire - you can rollback without any problems.
ashwinds said:
Voodoo does that - ie mount /data as ext4
Click to expand...
Click to collapse
So Voodoo actually reformats the space as EXT4, as opposed to mounting a virtual filesystem.... Interesting! I did read that Cyanogen were going to be using the Voodoo fix in their upcoming SGS firmware, will be keeping an eye on that for sure.
(Unless of course the official 2.2 remedies this.... though I'll keep an eye on Cyanogen anyway )
Do you have any information regarding development process of cyanogen for the SGS?
Any reason the voodoo fix is not mentioned? (Except for the fact we have to wait for beta2 to become available).
dagrim1 said:
Any reason the voodoo fix is not mentioned? (Except for the fact we have to wait for beta2 to become available).
Click to expand...
Click to collapse
Probably because if you don't already have it, it's not really available. V1 was a "private" beta, or semi-private anyways, and the dev has pulled it while he works on beta2.
distortedloop said:
Probably because if you don't already have it, it's not really available. V1 was a "private" beta, or semi-private anyways, and the dev has pulled it while he works on beta2.
Click to expand...
Click to collapse
Yeah, makes sense and clear
Is a great (and my favorite so far) alternative though... Should become available this week though.
Voodoo is definitely the most promising method IF they can get the kinks worked out. We'll see it when it gets there
@een625 makes a pretty good short comparison of all the methods, but leaves out Supercurio's method. This should be added to the second post:
-Supercurio's lagfix (aka Voodoo beta 1): Significant improvements in performance which can also be benchmarked. Requires a custom kernel.
This reformats the /data mount point as ext4. The conversion is automatic on first boot and no data is lost.
Pros: very fast, does not affect the amount of storage for apps, doesn't impact free space reporting, uses ext4 for data integrity which some argue is unnecessary, easy to install, easy to uninstall.
Cons: Semi-private beta release only, must be specifically uninstalled to upgrade some firmwares, uses ext4 which some argue is significantly slower than ext2, no longer easily available while beta2 is finalized
I personally use this one right now, it is the only one that I have never experienced lag with at some point, even after almost five days of continuous uptime and heavy use. All the others have issues from time to time, especially with the Market and installing apps. This one does not, in my experience.
Also, I think that there should be some mention that mimocan's method requires a custom kernel, and also that mimocan is pretty much the same as apps2sd on other Android phones (uses ext3/4 in a partition on the external card). Additionally, a con to mimocan is that the user must manually partition and format the external card, all of the other methods can be done without user intervention other than flashing a PDA or running a script/apk.
Finally, dkcldark had an update.zip method posted very briefly that reformats the /data to nilfs or ext4. Looked promising, but was pulled for some reason.
And last but not least, please, please, please, let's not let this thread devolve into the ext2 vs ext4 debate that so many of the individual lag-fixe threads turn into. Perhaps a thread dedicated to that should be started (and stickied)?
distortedloop said:
And last but not least, please, please, please, let's not let this thread devolve into the ext2 vs ext4 debate that so many of the individual lag-fixe threads turn into. Perhaps a thread dedicated to that should be started (and stickied)?
Click to expand...
Click to collapse
I'll keep the suggestion in mind
RAID lagfix?
Speed is one concern, potential damage to the flash card is another. I would prefer to replace my external card than the internal one.
Btw, is it technically impossible to implement more advanced solutions such as using a combination of NAND (for heavy apps / data) and sd (for other apps / "bulk" storage)?
Moreover, I think that it would be possible to have some kind a RAID 1 arrangement that would increase read speed and reliability (esp. if combined with EXT2). Just think 2GB on internal and 2GB on external card. (Most importantly having - probably - the first mobile phone with a raid configuration. RAID is easy to implement under Linux so I don't see why this is not examined.
Evans_Prophet said:
Speed is one concern, potential damage to the flash card is another. I would prefer to replace my external card than the internal one.
Btw, is it technically impossible to implement more advanced solutions such as using a combination of NAND (for heavy apps / data) and sd (for other apps / "bulk" storage)?
Moreover, I think that it would be possible to have some kind a RAID 1 arrangement that would increase read speed and reliability (esp. if combined with EXT2). Just think 2GB on internal and 2GB on external card. (Most importantly having - probably - the first mobile phone with a raid configuration. RAID is easy to implement under Linux so I don't see why this is not examined.
Click to expand...
Click to collapse
i think I might have even suggested something like this before, but it was either overlooked or its too hard to do. But the idea (i did not think about RAID) is awesome.
I agree Voodoo lagfix is great but there is one problem/phenomena: CON: Big battery drains and we don't know where it's coming from :S
Wouldn't RAID put a big strain on the CPU?
I've tried MoDaCo, Mimocan and RyanZA lagfixes.. for a very brief review, I've to say that MoDaCo seems the fastest to me.. Followed by RyanZa 1-click lagfix and lastly the Mimocan lagfix. A pity that MoDaCo is limited to ~130mb of /dbdata space
Btw, just my personal opinion.. Some may disagree and feels that other lagfixes are faster.
lafaya said:
I agree Voodoo lagfix is great but there is one problem/phenomena: CON: Big battery drains and we don't know where it's coming from :S
Click to expand...
Click to collapse
That seems to be a YMMV kind of thing. I don't notice big battery drains with it, but there are those who say they do. Not sure if I am lucky, or others are unlucky.
Certainly couldn't hurt to do the whole wipe batterystats routine and see what's up after that.
Chainfire said:
It is by now well known the SGS has a lag issue (apps slow to launch, email slow to access, etc) that can be fixed by changing filesystems for parts of the device, to make it blazingly smooth.
There are several fixes available, some based on SD card, some used through PC, some based on kernel flashing, some based on on-device apps, etc.
Click to expand...
Click to collapse
Thanks for doing this. I had been pushing for the change for the last couple of weeks since RyanZA and Tayutama particularly bought out their fixes. We now have a great range with Voodoo being the best atm imo.
Background:
Ok, so I write flash drivers for a living, so I would consider myself somewhat knowledgeable regarding flash technology.
The flash is erased in 128k blocks and written in smaller pages. Data, once written, cannot be changed until you erase, so the FS will write to another page and invalidate the current page. The 100k program/erase cycle count is on a per block basis. It is not being erased every time you write a file, so calm down, your phone isn't going to die. The 10 year data retention time that people are quoting has nothing to do with this. It is how long once programmed...and not changed...data is guaranteed to be valid for.
The only thing that you need to remotely consider...and needs to actually be verified, is whether RFS actually writes to the file system more or less than EXT4, and how much more. The data wear leveling is done on a lower layer than the file system and Dameon87 already confirmed both RFS and EXT4 are using the same sector translation layer.
Sources:
XDA Post linking RFS documentation: http://forum.xda-developers.com/showthread.php?t=801223
Reliability: http://www.samsung.com/global/busin...s/fusionmemory/Products_FAQs_Reliability.html
Datasheet: http://www.datasheetcatalog.org/datasheets2/12/1248447_1.pdf
Attached are app notes on RFS.
Regarding RFS:
RFS Programming Guide said:
STL Block Device Driver: This block device driver is used to provide driver functions for the device files /dev/stl0/*, /dev/stl1/* and so on. Since there is FTL between this block device driver and BML, it is allowed to perform random write requests and write requests are handled atomically. Thus any read-write file system (e.g. RFS) can run on this block device driver.
STL (Sector Translation Layer): translates a logical address from the file system into the virtual flash address. It internally has wear-leveling during the address translation.
Click to expand...
Click to collapse
Regarding EXT4:
EXT4 supposedly buffers more data before writing, thus in theory should require less program/erase cycles. This could in theory explain why people claim better battery life using EXT4. To program/erase flash, you must temporarily raise the flash voltage...this is why flashing ROMs and using ODIN drain your battery like crazy...and why you should always flash with a battery near 100%. This point is of course mute if there is no wear protection. If EXT4 is using the Samsung STL driver, the wear leveling should be implemented exactly the same as in RFS.
Regarding Bad Blocks:
It is typical to have some bad blocks in large flash arrays direct from the factory. It is normal and part of the manufacturing/validation process.
http://www.samsung.com/global/business/semiconductor/products/fusionmemory/Products_FAQs_Reliability.html said:
SAMSUNG guarantees the first block will operate properly during the 100K P/E cycle under normal conditions. On the other hand, other blocks can be invalid as long as the total number of bad blocks doesn't exceed 2% of all blocks.
Click to expand...
Click to collapse
Samsung Datasheet said:
The device may include invalid blocks when first shipped. Additional invalid blocks may develop while being used. The number of valid blocks is presented
with both cases of invalid blocks considered. Invalid blocks are defined as blocks that contain one or more bad bits. Do not erase or program factory-marked bad blocks.
Invalid blocks are defined as blocks that contain one or more invalid bits whose reliability is not guaranteed by Samsung. The information
regarding the invalid block(s) is so called as the invalid block information. Devices with invalid block(s) have the same quality
level as devices with all valid blocks and have the same AC and DC characteristics. An invalid block(s) does not affect the performance
of valid block(s) because it is isolated from the bit line and the common source line by a select transistor. The system design
must be able to mask out the invalid block(s) via address mapping. The 1st block, which is placed on 00h block address, is fully guaranteed
to be a valid block.
Within its life time, additional invalid blocks may develop with the device. Refer to the qualification report for the actual data.The following
possible failure modes should be considered to implement a highly reliable system. In the case of status read failure after
erase or program, block replacement should be done. Because program status fail during a page program does not affect the data of
the other pages in the same block, block replacement can be executed with a page-sized buffer by finding an erased empty block and
reprogramming the current target data and copying the rest of the replaced block.
Click to expand...
Click to collapse
Check your bad datablocks by doing this...
Code:
adb shell
su
cat /proc/L*/bmlinfo
You will probably have a few. I have 3. The block size is 128KB. 512MB/128KB = 4096 blocks (thats why they are using the bottom blocks in the 4000 range for the 2% coverage. 2% of 4096 is apx 81 bad blocks. But don't worry. You would have to get about 3 bad blocks per month for 2 years straight before a failure.
Conclusion:
Now of course the best way to extend the life of the flash is to use the SD card for partitions that get continually written to like /data...and don't flash new roms 100 times a day for 2 years. But you really don't have to worry about the dreaded flash fairy coming and breaking your phone after a week. Since FAT writes to the fixed location file allocation table over and over, Samsung already has the wear leveling in place. Moreover, RFS adds journaling and posix commands to FAT and was mounted with atime. Most likely, it was doing MORE file IO than EXT4. Below is a link to some info on EXT4 disk writes. Clearly using noatime and journaling off is the best option for flash with regard to longevity, however, the difference isn't as big as you would think.
Further Reading:
The Truth About RFS (warning lacks citation): http://forum.xda-developers.com/showthread.php?t=799931
EXT4 Performance testing: http://thunk.org/tytso/blog/2009/03/01/ssds-journaling-and-noatimerelatime/
Moved to general section for discussion.
Again, no flamming...
So in your opinion even if Ext4 degregades nand lets say 2-3 times faster than RFS,would Epic still function normaly with heavy daily use for 2-3 years?
Whosdaman said:
Moved to general section for discussion.
Again, no flamming...
Click to expand...
Click to collapse
Yeah, I should have put it in general. I wasn't trying to flame, but generally speaking, quoting ones self doesn't count as a valid citation.
lviv73 said:
So in your opinion even if Ext4 degregades nand lets say 2-3 times faster than RFS,would Epic still function normaly with heavy daily use for 2-3 years?
Click to expand...
Click to collapse
Code:
EXT4_lifecycle = RFS_flash_lifecycle * (EXT4_write_cycles/RFS_write_cycles)
plapczyn said:
Code:
EXT4_lifecycle = RFS_flash_lifecycle * (EXT4_write_cycles/RFS_write_cycles)
Click to expand...
Click to collapse
Thank you so much for your expertise on this matter plapczyn and for clearing up this dispute! I would add a thanks to you but alas, I have used all of mine today hehe! I suppose I may be one of the few (or many, who knows?) people who really enjoy reading technical responses that are beyond my personal understanding as they generally allow me to glean information that was previously out of my grasp! I really appreciate your detailed response!
Great information plapczyn.
But I think a lot of this stems to how ext4 behaves compared to rfs.
To be frank, I know very little about rfs beyond the fact that it's basically vfat with journaling support. To be honest, that sounds horrible...
ext4 on the other hand, I've got a decent grasp on it:
The real danger of writes with ext4 on nand flash comes from the meta-data blocks. Luckily in ext4 (unlike ext3), the meta-data blocks can be (and are) moved. The 128MB per block (in a 4KB block file system) restriction is removed (each 128MB block required a dedicated meta-data block).
Meaning, mke2fs (part of ext4) can MOVE the meta-data blocks around outside the large virtual block group as the are grown and shrank. Which means that the meta-data blocks aren't constantly written to the same spots, spreading out the meta-data writes across the storage.
The delayed allocation feature of ext4, in addition to the block allocator (mballoc) significantly reduces fragmentation -- in addition to vastly increasing performance. Decreased fragmentation means less move(); rename(); write(); delete(); operations to fit your data in the allocated blocks, thus decreasing wear on the nand (re-writing & updating meta-data) -- atleast in comparison to ext2/ext3. See the part above on how I know very little about rfs, I can't speak on how rfs handles fragmentation and block allocation. But considering how fragmented vfat gets...
But let's put some stuff into perspective:
Does ext4 create more I/O overhead (delete(); / write(); operations specifically) than rfs? Possibly. Some very valid questions were raised -- and questions like this NEED to be raised and debated.
journaling doesn't need to be enabled on your phone. That will alleviate a great deal of the writes if you are worried about it.
Is ext4 a good idea for nand flash on Linux running a database from a reliability stand point? Hell. No.
But a lot of writes in android's /system directory running ext4? Not likely. Sure it would wear out, but probably after a few years. Besides, doesn't samsung have wear-leveling in the controller to the nand? All Android and ext4 sees is the logical level. Which would render this whole argument moot.
msponsler said:
Great information plapczyn.
But I think a lot of this stems to how ext4 behaves compared to rfs.
To be frank, I know very little about rfs beyond the fact that it's basically vfat with journaling support. To be honest, that sounds horrible...
ext4 on the other hand, I've got a decent grasp on it:
The real danger of writes with ext4 on nand flash comes from the meta-data blocks. Luckily in ext4 (unlike ext3), the meta-data blocks can be (and are) moved. The 128MB per block (in a 4KB block file system) restriction is removed (each 128MB block required a dedicated meta-data block).
Meaning, mke2fs (part of ext4) can MOVE the meta-data blocks around outside the large virtual block group as the are grown and shrank. Which means that the meta-data blocks aren't constantly written to the same spots, spreading out the meta-data writes across the storage.
The delayed allocation feature of ext4, in addition to the block allocator (mballoc) significantly reduces fragmentation -- in addition to vastly increasing performance. Decreased fragmentation means less move(); rename(); write(); delete(); operations to fit your data in the allocated blocks, thus decreasing wear on the nand (re-writing & updating meta-data) -- atleast in comparison to ext2/ext3. See the part above on how I know very little about rfs, I can't speak on how rfs handles fragmentation and block allocation. But considering how fragmented vfat gets...
But let's put some stuff into perspective:
Does ext4 create more I/O overhead (delete(); / write(); operations specifically) than rfs? Possibly. Some very valid questions were raised -- and questions like this NEED to be raised and debated.
journaling doesn't need to be enabled on your phone. That will alleviate a great deal of the writes if you are worried about it.
Is ext4 a good idea for nand flash on Linux running a database from a reliability stand point? Hell. No.
But a lot of writes in android's /system directory running ext4? Not likely. Sure it would wear out, but probably after a few years. Besides, doesn't samsung have wear-leveling in the controller to the nand? All Android and ext4 sees is the logical level. Which would render this whole argument moot.
Click to expand...
Click to collapse
To clarify a single point, and I apologize if this is a stupid question, I have read and heard that disabling journaling does increase the risk of corrupted data but how real is that risk (meaning how much of a danger is it really?) and if data is corrupted would it effect the ability of the system to function or would it merely be 'cosmetic' (for lack of a better word) corruption?
Wear leveling for the OneNAND is implemented in software, not in hardware, in the STL as plapczyn mentioned in his post. From what I can tell, STL is responsible for exposing the OneNAND chip as a block device and from there, you can format the device using RFS, YAFFS, EXT4 or whatever.
Another note here is that the type of wear-leveling that RFS and YAFFS do is called dynamic wear leveling which means wear-leveling is only done on write ops as I understand it. SSDs use static wear leveling that is capable of moving, for example, data from blocks that change rarely over to blocks that change frequently in an effort to give said blocks a chance to "rest". The wear-leveling in RFS and YAFFS doesn't do this.
In addition, SSDs include extra NAND chips and only expose some percentage of the total capacity so that extra blocks are available for wear leveling. From what I understand, the OneNAND chip has no "extra" capacity for this purpose. This means that the more total space you allocate with static data, the quicker you'll run into problems because you'll be reusing a smaller set of blocks over and over for writes. This can be overcome with careful partitioning and, of course, maintaining a reasonable amount of free space.
But, dynamic wear leveling is used in USB memory sticks and most flash memory cards as well (including Micro SDHC cards which is why they can stay on FAT/FAT32 without issues). Lots of folks run, for example, web browsers off USB memory sticks for years - I have an old 1GB drive that's several years old and I keep a copy of PortableChrome on it. All the transient data like the browser cache and history files are kept on the stick and I haven't run into any problems yet. Also note that the MLC NAND chips typically found in these devices are only rated for 10,000 P/E cycles instead of the 100,000 for SLC chips like the OneNAND.
I'm sure that someone can concoct some nightmare-scenario or torture test that will easily result in blowing past the P/E cycle limit on some blocks but realistically speaking, it would need to be a LOT of continuous activity to run into those limits. Overall, even with EXT4, the OneNAND chip is going to be far more durable than your average USB memory stick or memory card for your camera. Granted, the usage patterns aren't exactly the same but then again, OneNAND is good for an order of magnitude more P/E cycles vs. the MLC chips found in these solutions.
Journaling is there in order to rebuild data in the event of a power loss mid write.
A journal will rebuild the last write operation, staving off data corruption.
But let me ask you this...do you routinely start copying files on your phone and pull the battery? Probably not. Which is why journaling isn't very important on phones. You just have to wait the extra 10 seconds for the phone to shut down.
msponsler said:
Journaling is there in order to rebuild data in the event of a power loss mid write.
A journal will rebuild the last write operation, staving off data corruption.
But let me ask you this...do you routinely start copying files on your phone and pull the battery? Probably not. Which is why journaling isn't very important on phones. You just have to wait the extra 10 seconds for the phone to shut down.
Click to expand...
Click to collapse
Wonderful! Thank you for clearing that up!
So question, since Ext4 is efficient for stuff like usb style flash etc, and "bad"(note the quotes cuz of the claims) for phone style flash, wouldnt it be beneficial if the kernel/initramfs supported it to multi-format? essentially a partial "lagfix" where /cache and /data get partitioned to a mount on the SD and the multi writes/reads and the kernel and /system lives on the onenand, while moving the datadb partition to rfs?
more or less a hybrid where you gain the advantages of each, potentially a performance boost and reduce the wear and tear so to speak?
** just thinking of it all would love an explanation if im wrong in my thinking of behaviors of it.
*** Also because CW 3.0.0.5 supports the ability to partition however you tell it, yopu could multi partition this way, also couldnt we technically mimic google and shift to yaffs pretty easy as well(same way we did with ext4)?
art3mis-nyc said:
So question, since Ext4 is efficient for stuff like usb style flash etc, and "bad"(note the quotes cuz of the claims) for phone style flash, wouldnt it be beneficial if the kernel/initramfs supported it to multi-format? essentially a partial "lagfix" where /cache and /data get partitioned to a mount on the SD and the multi writes/reads and the kernel and /system lives on the onenand, while moving the datadb partition to rfs?
more or less a hybrid where you gain the advantages of each, potentially a performance boost and reduce the wear and tear so to speak?
** just thinking of it all would love an explanation if im wrong in my thinking of behaviors of it.
*** Also because CW 3.0.0.5 supports the ability to partition however you tell it, yopu could multi partition this way, also couldnt we technically mimic google and shift to yaffs pretty easy as well(same way we did with ext4)?
Click to expand...
Click to collapse
Exactly. It shouldn't matter if the RO partitions (system, kernel, radio) are formatted as EXT4 because the whole concern regarding program/erase cycles is mute. We should use whatever gives the best performance. Also, if it is truely that big of a deal, we could always go to YAFFS the same way we did with EXT4. Since google announced EXT4 as the default FS for 2.3+, I doubt it really was 'necessary' for YAFFS on the NAND. It is possible...that they chose to use a different low level device driver (faster?) and do the wear leveling in the FS layer.
While still on the subject,how come none of these devs use RaiserFS in their roms?Raiserfs suposed to be real fast with small files.There are few Evo/Nexus roms/kernels with Raiserfs implemented and users report big speed boost over Ext4.
lviv73 said:
While still on the subject,how come none of these devs use RaiserFS in their roms?Raiserfs suposed to be real fast with small files.There are few Evo/Nexus roms/kernels with Raiserfs implemented and users report big speed boost over Ext4.
Click to expand...
Click to collapse
There must be a reason devs have not ported this. Perhaps there are issues?
Look, Im pretty techie myself, been a server administrator/architecht for 25+ years....linux, vmware, windows, etc. So I'm not dumb lol. Just wanted to understand a bit more....please bear with me on this....but can someone line-item out what benefit ext4 is going to give me on my epic running froyo?
maybe something like:
epic with dk28 (froyo) non-ext4 : blah blah
epic with DK28 (froyo) on ext 4 : blah blah PLUS blah BLAH brrrb BLAH and its faster or whatever.
ThoughYou could move to reiserfs. I used it for many yeas, and I greatly enjoyed it.
However...reiserfs is a dead project. Hans reiser is in jail for mudering his wife. Reiserfs isn't without its problems though. It works we'll with files under 4kb. But it still uses the "big kernel lock", which is not the way to go IMHO. And reiserfs does suffer from degredation over time.
As far as the benefits of ext4:
Extents replacing block mapping improves I/O performance. It uses h-trees in the meta-data to drastically improve file location time. Actually mathematical genius...
Mutiple block allocators improve I/O time.
Ext4 is multi-threaded...yaffs2, rfs, ext2/3 are not
Allocate on flush, meaning blocks arent written until the data is ready. You'll sacrifice cpu/memory for I/O through put, but it does improve performance while reducing fragmentation.
15 years as a Linux and Solaris admin and engineer here. Always nice to meet another SA / Engineer!
hmmm ext4 is multi-threaded how?
let me throw a bit of what i understand here into the equation and ask differently....vmfs3 (esx filesystem) is comparable to ext3 right ? seems like I can multi-thread like a maniac on that filesystem with umpteen vms right? so basically ext4 is just another filesystem, like fat16 and ntfs, etc , and so we are just seeing the benefits of something written for newer SSD hardware in ext4?
Not trying to be any more newbish lol decided to just research more and found this little article....
http://www.phoronix.com/scan.php?page=article&item=ext4_btrfs_nilfs2&num=7
change the last number in the link to review the whole 7 page article.
It looks to me that ext4 is an upgrade over ext3 and shouldnt be such a big worry - as you said, it seems to have less frag problems, can write faster, writes in a different manner in order to get better throughput.
rhel6 pushes ext4 as a default, with btfrs as an option - which the above link basically proves to me with their testing. In short, ext4 is ready for primetime and works well for linux systems. And the others might not be.
So if you want a little more out of your phone, go ext4. want to be safe, stay where you are.
Since most of us wont have this phone in even 1 more year, more performance is the reason we are here anyways lol...so ext4 here I come I guess )
and a big SUP! to a fellow SA ) thanks for the info, I appreciate it.
msponsler said:
You just have to wait the extra 10 seconds for the phone to shut down.
Click to expand...
Click to collapse
Does this mean that I shouldn't be using QuickBoot while running an ext4 file system with journaling disabled?
aal1 said:
hmmm ext4 is multi-threaded how?
Click to expand...
Click to collapse
EXT4 isn't multi-threading but it supports file-level locking. YAFFS only supports partition-level locking. That means that only a single thread can write to a YAFFS partition at any moment in time. So long as that thread has a lock open, all other write operations to that partition are blocked until the lock is released.