Re: Problem with Maemo Mapper 1.4 and SD's
 

I've mentioned this observation before, and although I haven't been bored enough to try myself, I imagine formatting an entire memory card with JFFS2 instead of VFAT (or even ext2/3) would pretty much eliminate the internal fragmentation issues. Plus, it would introduce wear-leveling to extend the life of the memory card.

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

Re: Problem with Maemo Mapper 1.4 and SD's
 

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.

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.

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.

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.

Re: Problem with Maemo Mapper 1.4 and SD's
 

Isn't that done transparently by the card firmware?

Re: Problem with Maemo Mapper 1.4 and SD's
 

That depends on the card itself, I think. You're right, though, most memory cards implement wear leveling at the hardware level.

Re: Problem with Maemo Mapper 1.4 and SD's
 

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... :-)

Re: Problem with Maemo Mapper 1.4 and SD's
 

Thanks for correction.
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.

Re: Problem with Maemo Mapper 1.4 and SD's
 

Yes, it should be possible, check this
http://www.gossamer-threads.com/lists/maemo/users/10585
Repartitioning should not be needed, just reformatting (mke2fs) and some modification of system files.

Maybe :-)
It should be possible to see such ext2 formatted card in file manager so this is not needed.

Re: Problem with Maemo Mapper 1.4 and SD's
 

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.