I have the TMOUSA version, but I think this question would apply to all versions, and in fact to other phones as well.
I was just re-reading the excellent guide to storage card optimization by the great Windows Mobile guru (and XDA member) who writes under the name Menneisys:
http://www.smartphonemag.com/cms/forum/topic/17921?&TOPIC_ID=17921
That article was written a few years ago, though, with older WM versions, and older storage cards.
I am wondering if the info is still relevant, to a new phone like the HD2, with WM 6.5 and Sense, and the newer storage cards?
The 16MB storage card that comes with the HD2, although the newer SDHC type, is only Class 2, therefore relatively slow, compared to Class 4 and Class 6 cards. I am wondering if using any of the tweaks suggested in the article by Menneisys would speed up the card.
For instance, changing from FAT32 to FAT16? (FAT16 is really ancient now though, don't know if it would work well at all on newer cards and devices.)
Eliminating the FAT backup?
Also, by changing to a larger cluster size? (Which of course, would reduce the storage space, by adding more slack. But would it speed up the card's performance enough to make it worth it?)
Of course defragmentation is always a good idea, with any disk or card, old or new. That part of his advice is not in question, then or now.
But I am wondering about the other stuff--like changing to FAT16, eliminating the FAT backup, and changing the cluster size?
Anyone know? (Menneisys, are you reading? Others?)
Thank you.
well, without reading the link, (i'll save that till the kids are in bed) i can say that fat16 can't address 16gb, however re the cluster size, yes, that can deff help, especially if you have lots of fairly large files. if your card is mostly music images and video, then you can deff benefit from setting the size as large as it will go. it does mean tiny files will take up a whole block, of course, but if its mostly big files then go for it.
samsamuel said:
well, without reading the link, (i'll save that till the kids are in bed) i can say that fat16 can't address 16gb, however re the cluster size, yes, that can deff help, especially if you have lots of fairly large files. if your card is mostly music images and video, then you can deff benefit from setting the size as large as it will go. it does mean tiny files will take up a whole block, of course, but if its mostly big files then go for it.
Click to expand...
Click to collapse
Very interesting article. Yes, do read it when you have a chance.
Yes, probably SDHC cards did not exist at the time of the article, nothing larger than 2 GB. So, sounds like the FAT16 option is out for current cards.
Do you know if that option of formatting a card with "no FAT backup" still makes sense on current cards? Is it a risky thing to do?
Regarding the cluster size-- most of us probably have both small and large files, not only one or the other. So, it is a trade-off between speed and storage space. What cluster size do you think is a good balance between the two?
never read anything about fat backup, so i couldn't say. as for block size, i use 16k on a 2gb card, which has 1gb of music and about 300meg images.
i would say the lost space is negligible on sdcards, even if you have a thousand 1k files, you only waste 16meg, so that's maybe 1/2 an mp3 album,, its only really an issue when dealing with hundreds of gig hard disks with tens of thousands of tiny system and program files. (just checked mine, theres only 250 files smaller than 32k, and only 120 less than 5k)
course, its a matter of preference, and i'm sure there are loads of people will say i'm wasting space and should be disowned from the community,, hehe
samsamuel said:
never read anything about fat backup, so i couldn't say. as for block size, i use 16k on a 2gb card, which has 1gb of music and about 300meg images.
i would say the lost space is negligible on sdcards, even if you have a thousand 1k files, you only waste 16meg, so that's maybe 1/2 an mp3 album,, its only really an issue when dealing with hundreds of gig hard disks with tens of thousands of tiny system and program files. (just checked mine, theres only 250 files smaller than 32k, and only 120 less than 5k)
course, its a matter of preference, and i'm sure there are loads of people will say i'm wasting space and should be disowned from the community,, hehe
Click to expand...
Click to collapse
Read the Menneisys article, and he says it makes the card run a lot faster, to eliminate the FAT backup. (Something you can do with SK Tools.)
However, I would wonder if that would make the card less stable, more prone to data loss. Or, even whether a non-standard cluster size might make the card more flaky?
does wm 6.5 support exfat?
using 16G thumbdrive on win 7, exfat is wayyyy faster than ntfs.
I used the 8GB card at the beginning, switched then to a 16GB card class 6 and then to 32 GB class 2 and din´t find the slightest dfifference in speed, neither when recording videos with the cam in max resolution.
me said:
Read the Menneisys article, and he says it makes the card run a lot faster, to eliminate the FAT backup. (Something you can do with SK Tools.)
However, I would wonder if that would make the card less stable, more prone to data loss. Or, even whether a non-standard cluster size might make the card more flaky?
Click to expand...
Click to collapse
lets take a step back and think about what the FAT backup is. i believe it is another table that mirrors the contents of the primary table. essentially, it can be used to recover your file system table in case the primary backup is corrupted/lost. now lets think about WHEN this table is read. to the best of my knowledge, the backup is read ONLY if the primary is found to be corrupted. similarly, the backup is UPDATED/WRITTEN only when the primary is UPDATED/WRITTEN.
thus, any speed gain due to disabling the backup should be seen in WRITE operations ONLY. read speed should be not be affected by that tweak. i could be wrong though!
if i am correct, then try disabling the backup if you desire write speed. however, you will lose some of the "robustness" of the file system. and FAT (and its variants like FAT12, FAT16, FAT32) are already fairly fragile file systems.
regarding cluster sizes, a smaller cluster size means LESS wastage when having many SMALL files. a larger cluster size means MORE wastage when having many SMALL files. however, a smaller cluster size means MORE clusters to address, which means a LARGER allocation table, which means MORE TIME spent looking up/updating the table's contents. conversely, a larger cluster size means LESS clusters to address, which means a SMALLER allocation table, which means LESS TIME spent looking up/updating the table's contents. so the sweet spot would be somewhere in the middle. HOWEVER, most modern operating systems load the allocation table in MEMORY so i imagine the speed gain would be negligible. the fact that the table is managed in memory and periodically updated back to the disk is the reason behind most corruptions in a non-journaling file system like FAT.
i've over simplified things a bit, but it should give you an idea of what kind of gains to expect by such tweaking (i.e. little to none in my opinion!).
Again, I'd suggest reading the Menneisys article.
ASCIIker said:
lets take a step back and think about what the FAT backup is. i believe it is another table that mirrors the contents of the primary table. essentially, it can be used to recover your file system table in case the primary backup is corrupted/lost. now lets think about WHEN this table is read. to the best of my knowledge, the backup is read ONLY if the primary is found to be corrupted. similarly, the backup is UPDATED/WRITTEN only when the primary is UPDATED/WRITTEN.
thus, any speed gain due to disabling the backup should be seen in WRITE operations ONLY. read speed should be not be affected by that tweak. i could be wrong though!
if i am correct, then try disabling the backup if you desire write speed. however, you will lose some of the "robustness" of the file system. and FAT (and its variants like FAT12, FAT16, FAT32) are already fairly fragile file systems.
regarding cluster sizes, a smaller cluster size means LESS wastage when having many SMALL files. a larger cluster size means MORE wastage when having many SMALL files. however, a smaller cluster size means MORE clusters to address, which means a LARGER allocation table, which means MORE TIME spent looking up/updating the table's contents. conversely, a larger cluster size means LESS clusters to address, which means a SMALLER allocation table, which means LESS TIME spent looking up/updating the table's contents. so the sweet spot would be somewhere in the middle. HOWEVER, most modern operating systems load the allocation table in MEMORY so i imagine the speed gain would be negligible. the fact that the table is managed in memory and periodically updated back to the disk is the reason behind most corruptions in a non-journaling file system like FAT.
i've over simplified things a bit, but it should give you an idea of what kind of gains to expect by such tweaking (i.e. little to none in my opinion!).
Click to expand...
Click to collapse
These tests might be of some interest to you.
http://forum.xda-developers.com/showthread.php?t=756781&highlight=card+speed+test
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
I defragged my SD and the performance gain was considerable. Is there any program that can defrag the main memory or the Storage?
i used my cardreader, but i think that's diffrent :?
Defragmenting flash or SD memory is useless since every address on the chip has the same access time. Defragmentation only makes sense with devices like hard disks, where the relative location of data plays a role.
is there any way of defragmenting the device itself not the SD card
Dandie said:
Defragmenting flash or SD memory is useless since every address on the chip has the same access time. Defragmentation only makes sense with devices like hard disks, where the relative location of data plays a role.
Click to expand...
Click to collapse
Not quite sure I understand your response. Using Pocket Mechanic, I can format the SD card with FAT16 or FAT32. Both file systems can become fragmented...
BTW, Pocket Mechanic can defragment the internal storage memory (if you rename it to something other than "Storage" - it seems to have a problem with the default Magician file name), but NOT the main memory file system.
stevedebi said:
Dandie said:
Defragmenting flash or SD memory is useless since every address on the chip has the same access time. Defragmentation only makes sense with devices like hard disks, where the relative location of data plays a role.
Click to expand...
Click to collapse
Not quite sure I understand your response. Using Pocket Mechanic, I can format the SD card with FAT16 or FAT32. Both file systems can become fragmented...
Click to expand...
Click to collapse
Yes, they can become fragmented, even NTFS can get fragmented although MS designed it not to. But that is besides the point, as pointed out before. Defragmenting can speed up (and mechanically relieve) all devices that use mechanical means to retrieve the data. On a hard disk there are tracks kind of like on an old vinyl audio media. Fragmentation in this context means you want to listen to track 1,3,7,9 and 11. So you have to lift the needle after each track and reposition it. Same happens when a hard disk wants to read a file smeared across multiple tracks on the disk platter. It reads some part, then has ro reposition the head and keep reading. Defragmenting puts the data of one file into one long track so the time needed for positioning is eiliminated. In the analogy that would be pressing a new vinyl disk that only contains the tracks desired (1,3,7,9,11) just one after another. You won't have to lift the needle anymore.
This is the theory. But for memory chips (all kinds, be it RAM, ROM, USB-Sticks, SD-Cards, ..., any storage media with NO MOVING Parts) this is not applicable. When the system wants File A it looks in the File Table where that file is located. Then it gets a list of positions and starts requesting the contents of these positions from the card device. The access time to any of these positions is exactly the same. Go back to the audio comparison. For a vinyl disk you have to lift and reposition the needle if you selectively want to hear certain songs only. If you had the same album on a MP3 player or other device you can arrange your playlist and no matter in which order or position the tracks are the time until the player starts playing them is the same.
Hope that clears it up. I am actually not too sure why the PocketMechanic author has put in Defragmentation. It does not make sense to me. Maybe on FAT devices there is a slight advantage to having the files en bloc because that way their position data is more compact (just START-END or something as opposed to START1-END1 ... START2-END2 ...) but I am not sure about this. Even if this was the case your only gain would be a few bytes of SPACE not TIME.
Takes ages too to defragment a SD-card. So if you insist in defragmenting you'd better put your SD in a card-reader & transfer the contents to your harddisk, format the card if you like (faster than deleting) or delete everything & transfer everything back.
M
STAY AWAY from defragging flash memory!!!
1.) This doesn't help anything, it won't be faster. Flash memory is adressed directly (like already said) and doesn't need to be defragged.
2.) If you want (for whatever reason) the files to be in one piece (that's what defragging does) on the flash memory, simply copy the contents of the card to the PCs harddisk, reformat the card and copy the stuff back on. This has the same result as defragging.
3.) Defragging will destroy you card! Flash memory has a limited amoung of read/write cycles before the will die someday. It's unlikely you'll ever see that in real life use because read/write cycles are used faithfully by PPCs. However defragging uses an insane amount of read/write cycles since data is read and written so often from one point to another that it will shorten the lifetime of the card noticeably.
I don't know why defragging of flash memory is offered at all, it's no good at all and only damages the cards in the long run. But maybe it's a feature that has to be "there".
Wow, I never knew that. :!: I had been faithfully defragging my SD once every few months; I am going to stop doing that.
Always learn something new around here! 8)
Well, best is to use that format method and move the contents to the PC and after formating the flash memory card copy the stuff back on. This has the same effect as defraggin, takes much less time (since defraggin flash mem in a PPC is not that fast at all) and has no negative effect on the lifetime. I tend to do that once in 2-3 month. But the speed gain is not even worth mentioning, it's basically nonexistant.
a nice guide that should be shared with everyone
http://pocketpcmag.com/forum/topic.asp?TOPIC_ID=17921
In general, to get the highest write rates you should format the storage card with as large a cluster as you can and most of the time the FAT16 file system is faster than FAT32.
very interesting read, seems unless you have one of the cards specified in the article then trial and error formatting may award you with increased card performance. I think ill give it a go and see how it pans out, a cpl extra milliseconds read time never hurt and might speed up the odd game or picture or two.
There is a thread running about this subject: Formatting the storage card
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
Anyone know good partition settings for the sd card? I've been troubled simply because clockwork doesn't really do it all well. I'm using linux, I love the disk management on linux Thanks for the info!
What do you mean 'good partition settings'? Sizes or more like types of partitions like Linux Swap, ext2,3,4...? With Android there's not much use for anything beyond basic Linux partitions (0x83) like ext2,3,4 and Linux Swap (0x82). Even at that, ext2 is all you really need - maybe ext3 for good measure. This whole deal with ext4 is crazy since our file systems are not even remotely close to being large enough to see a benefit from ext4, only a very tiny slight benefit, almost unnoticeable for the most part. The placebo effect works wonders IMO. Might as well use it though, since it doesn't take anymore time.
As far as swap, we don't need it on this phone really and even with a class 6 card it still slows you down. Use compcache. It should be faster assuming current ROMs retain the fix cyanogen put in back in the G1 days.
thanks
KCRic said:
What do you mean 'good partition settings'? Sizes or more like types of partitions like Linux Swap, ext2,3,4...? With Android there's not much use for anything beyond basic Linux partitions (0x83) like ext2,3,4 and Linux Swap (0x82). Even at that, ext2 is all you really need - maybe ext3 for good measure. This whole deal with ext4 is crazy since our file systems are not even remotely close to being large enough to see a benefit from ext4, only a very tiny slight benefit, almost unnoticeable for the most part. The placebo effect works wonders IMO. Might as well use it though, since it doesn't take anymore time.
As far as swap, we don't need it on this phone really and even with a class 6 card it still slows you down. Use compcache. It should be faster assuming current ROMs retain the fix cyanogen put in back in the G1 days.
Click to expand...
Click to collapse
Thanks. I ended up re flashing clockwork and the partition worked for some reason. On another note, I havent' been able to format my sd card directly from the android storage settings for some reason. This has happened on stock and any CM rom I use. Think I have a bad sd card?
llontop.m said:
Thanks. I ended up re flashing clockwork and the partition worked for some reason. On another note, I havent' been able to format my sd card directly from the android storage settings for some reason. This has happened on stock and any CM rom I use. Think I have a bad sd card?
Click to expand...
Click to collapse
Could be but I've never had that issue before, nor have I heard of it happening - that's not to say it doesn't. Try to search around on here and see what you come up with. Try the Nexus 1 or G1 forums since you're more likely to find an answer there.