Active Topics
-
Porting apps to Leste (29)
to Maemo 7 / Leste by Arno_11 - 3 days, 9 hrs ago -
Install Fonts in N900 (68)
to Maemo 5 / Fremantle by teroyk - 4 days, 13 hrs ago - more...
|
2007-06-04
, 19:18
|
|
Posts: 165 |
Thanked: 5 times |
Joined on Jan 2007
@ Boston MA USA
|
#12
|
Originally Posted by fanoush
I was speaking specifically about SD card formatting on WinXP SP2; sorry for the omission. Feel free to try it yourself, the OS apparently treats these cards (and presumably other removable media types) differently from hard drives, where 4KB is the default FAT32 cluster for volumes from 257MB through 8GB. Then it's 8KB up to 16GB volumes, and 16KB up to 32GB volumes.
Originally Posted by jpjOn which system? On most systems default FAT32 cluster size is 4KB no matter the size.In fact the default FAT32 cluster size is 16KB for a 1GB SD card and 32KB for anything larger (up to the 8GB SDHC currently available).
Are you sure about this? is this result of some practical test?
Win2K and XP accept FAT32 volumes >32GB but will not create them. However, NTFS defaults to 4KB clusters for anything between 2GB and 2TB. Maybe this is what you were thinking of, since it's what we find on most large Windows hard drives these days.
I assume there is some architectural reason for treating flash cards differently, since the industry supplied SD card formatters also use larger clusters than the hard drive defaults. For example, if the internal write logic always uses large blocks, writing sub-blocks becomes a very wasteful read-modify-write operation.
Originally Posted by fanoush
As you are no doubt aware, the OS implementation trumps pure math. ;-) In other words, the designers might have imposed the artificial limit on cluster count (which can be confirmed by an MSKB search) due to the efficiency concerns you cite. Or maybe they just clamped the lid because of complaints about the 16-bit Windows 98/ME ScanDisk, which yields the same constraint.
While I'm not sure anything below 4KB block is supported with FAT32 at all, pure math says limits should be different. 4GB fits inside 32bits even when you address it by individual bytes, here you are addressing by clusters so why you can't have 512 bytes sized cluster with 4gb card? That should give you 2^32(=4294967296)/2^9(=512)= 8388608 clusters which should definitely fit into 32 bits of FAT32 limit. So in theory you could have 2^(32+9) bytes big card for 512 cluster size. Or if inforamation here http://www.cknow.com/ckinfo/f/FAT-Fi...tionTable.html or here http://en.wikipedia.org/wiki/File_Allocation_Table is true (and it probably is) and only 28 bits are used is still should allow 2^(28+9=37)=128GB card to have such small cluster.
Anyway making the cluster size small will make FAT table quite big. Generally it may not be very good idea to choose size below 4KB on gigabyte sized cards. Check this
http://www.storagereview.com/guide20...partFAT32.html
4GB card with 1KB block would give you FAT table size of 16MB and 512 bytes cluster will take 32MB.
Since most devices are not caching writes and keep FAT table in RAM and update it on every write this could make such card very slow and even not working in devices like PalmOS handhelds or digital cameras (due to device RAM limit).
But maybe linux is clever enough and handle big FAT tables sensibly so in N800 this could work?
One could write an alternative formatter (or use the Win98/ME version) that produces a consistent FAT32 volume outside the Win2K/XP limits, and such a volume would probably work in practice (mostly). On the other hand, it can be expected to confuse other system components that were designed around the official constraints. Come to think of it, I might dust off an old Win98 SE startup disk and experiment, or just try hacking the version check code in its FORMAT.COM ... and there's always FREEDOS ...
In any case, I agree with your concern over the downside of large FAT tables, especially on SD cards. I consciously accept this tradeoff for my mapper files because it works well for that purpose, even though loading the card is painfully slow. As I mentioned, I have another large card containing mostly MP3 files, where I use the default 32KB SDHC clusters.
|
|
2007-06-04
, 19:20
|
|
Posts: 165 |
Thanked: 5 times |
Joined on Jan 2007
@ Boston MA USA
|
#13
|
Originally Posted by gnuite
Isn't that done transparently by the card firmware?
Plus, [JPPFS] would introduce wear-leveling to extend the life of the memory card.
 |
|
2007-06-04
, 21:15
|
|
Posts: 1,245 |
Thanked: 421 times |
Joined on Dec 2005
|
#14
|
Originally Posted by jpj
That depends on the card itself, I think. You're right, though, most memory cards implement wear leveling at the hardware level.
Isn't [wear leveling] done transparently by the card firmware?
|
|
2007-06-05
, 08:08
|
|
Posts: 10 |
Thanked: 0 times |
Joined on May 2007
|
#15
|
Now that this thread has diverted a bit from the original, I'll add some details...
First, I formatted my 4 GB SDHC card in sfdisk while doing the "start from MMC" routine and tried formatting to FAT32, by using a different flag for fs type - I used option b in place of 6 (see posts regarding starting from MMC) and got a FAT32 - File manager showed 3,7 GB at first. But I had to reformat it in Win because N800 only could use 2 GB of the partition - after reboot File manager told 2 GB...
Now I have loaded some 900+ MB of maps (1,45 GB used on disk) onto it and the system starts to get real slow. Would it be possible to use an ext2 fs for the map files? How would that be accomplished, other than repartitioning and such in sfdisk? Would it help, as in not making Canola crawl like it does now?
Also, how to tell MM that the maps should go to a folder that cannot be seen in the File manager? It is a nuisance that the OS only knows to show FAT disks in the manager, but I'm not going to try and install KDE to fix it... :-)
First, I formatted my 4 GB SDHC card in sfdisk while doing the "start from MMC" routine and tried formatting to FAT32, by using a different flag for fs type - I used option b in place of 6 (see posts regarding starting from MMC) and got a FAT32 - File manager showed 3,7 GB at first. But I had to reformat it in Win because N800 only could use 2 GB of the partition - after reboot File manager told 2 GB...
Now I have loaded some 900+ MB of maps (1,45 GB used on disk) onto it and the system starts to get real slow. Would it be possible to use an ext2 fs for the map files? How would that be accomplished, other than repartitioning and such in sfdisk? Would it help, as in not making Canola crawl like it does now?
Also, how to tell MM that the maps should go to a folder that cannot be seen in the File manager? It is a nuisance that the OS only knows to show FAT disks in the manager, but I'm not going to try and install KDE to fix it... :-)
|
|
2007-06-05
, 08:49
|
|
Posts: 2,152 |
Thanked: 1,490 times |
Joined on Jan 2006
@ Czech Republic
|
#16
|
Originally Posted by jpj
Thanks for correction.
the OS apparently treats these cards (and presumably other removable media types) differently from hard drives, where 4KB is the default FAT32 cluster for volumes from 257MB through 8GB.
Originally Posted by jpj
Yes, that may be one reason (together with speed and RAM limitations of various devices). But since this works transparently you never know. For example even if you choose bigger blocks then due to partition table and other alignment, beginning of such big block may not align with beginning of internal block so you'll get multiple writes and read-modify-write anyway. I guess there is probably some sophisticated controller on the card to handle wear leveling and bad blocks and there is probably also some spare area with unused blocks so I guess it is same like with harddisks now - you don't know the real geometry, it is just array of blocks and any guesses may be wrong or may even change after card is used for some time.
I assume there is some architectural reason for treating flash cards differently, since the industry supplied SD card formatters also use larger clusters than the hard drive defaults. For example, if the internal write logic always uses large blocks, writing sub-blocks becomes a very wasteful read-modify-write operation.
|
|
2007-06-05
, 09:02
|
|
Posts: 2,152 |
Thanked: 1,490 times |
Joined on Jan 2006
@ Czech Republic
|
#17
|
Originally Posted by lite
Yes, it should be possible, check this
Would it be possible to use an ext2 fs for the map files? How would that be accomplished, other than repartitioning and such in sfdisk?
http://www.gossamer-threads.com/lists/maemo/users/10585
Repartitioning should not be needed, just reformatting (mke2fs) and some modification of system files.
Originally Posted by lite
Maybe :-)
Would it help, as in not making Canola crawl like it does now?
Originally Posted by lite
It should be possible to see such ext2 formatted card in file manager so this is not needed.
Also, how to tell MM that the maps should go to a folder that cannot be seen in the File manager?
|
|
2007-06-05
, 15:18
|
|
Posts: 1,245 |
Thanked: 421 times |
Joined on Dec 2005
|
#18
|
Originally Posted by lite
You don't technically have to use the "Browse..." button - it's there for convenience. You can enter arbitrary text in the Repository Directory field. Just find out the pathname of the directory you'd like to use (e.g. using xterm), and enter that pathname into the field.
Also, how to tell MM that the maps should go to a folder that cannot be seen in the File manager? It is a nuisance that the OS only knows to show FAT disks in the manager, but I'm not going to try and install KDE to fix it... :-)
Has anyone tried this? Can JFFS2 even support file systems that large? I guess the only (consumer) problem is a lack of Windows-accessible JFFS2 formatters...