Wiki page - which file system in sd card?

[Fernando Martins]

Hi,

Based on list feedback, I have rewritten my former proposal for a wiki 
page dealing with the choice of file system for sd cards. If you feel so 
inclined, please review the text below before I put it on the wiki. I 
was thinking to link it from the FAQ page, under Storage, modulus a 
better suggestion.

I would love to have benchmarking info there, both for performance and 
storage efficiency.

Cheers,
Fernando

=====
This page summarises some aspects of file systems on SD Cards based on a 
thread in the OpenMoko community list: 
http://lists.openmoko.org/pipermail/community/2009-January/040521.html

I got a new SD card. Which file system is the best?
Short answer: ext3. Other options: ext2, vfat. Don't use wear-aware file 
systems like jffs2 and ubifs.

Long answer:
In principle you can use any file system that is supported by the kernel 
in your Open Moko, commonly FAT, ext2, and ext3, and reiserfs. The main 
difference between the first two and second two, is that the second set 
(ext3, reiserfs) supports journaling.

The journal is an extra data structure used to make sure that the file 
system is always in a consistent state. Typically, if a crash happens in 
the system, the file system might get corrupted and even become 
unusable. In simple terms, the fs first saves all the data needed to 
perform the operation in the journal and only then starts updating the 
file system. If something goes wrong, the fs can rely on the journal to 
safely repeat the operation and repair the file system. Without a 
journal, the operation will certainly be lost and it might not even be 
possible to fix the file system.

If you read the mail thread, you'll see people both vouching for fat and 
ext2 but also others experiencing corruption and annoyed with both file 
systems. Since not many people are recommending reiserfs nowadays due to 
lack of maintenance, regardless of being considered better than ext2/3, 
ext3 remains as the choice.

There are three disadvantages with the journaled file system:
- lower performance at write time, since there is the extra work of the 
journal
- increased chance of damaging the SD card due to extra use of the 
journal causing wearing
- increased space usage (for the journal)

Regarding performance, if you are using the SD mostly for static storage 
like maps or music files, it should not be a big problem. After the 
initial storage phase, the reads won't be delayed by the journal.

Regarding the extra wearing, the number of write accesses before wearing 
seem to be sufficiently high not to have to bother with it, and the SD 
card in itself as automatic wearing leveling which will ensure that the 
journal will be written in another place after some time. All in all, sd 
card damage due to the journal should not be a practical issue.

FAT might already be the fs in your card when you got a new one. It has 
the advantage of being recognised in many other systems. The data 
structures are simpler which might mean less writes on the sd-card and 
less code being executed (unverified) and you'll find more tools 
available to recover
information when you get errors.

But even if you use ext3 in the SD Card you should be able to have 
access to it through the USB interface, instead of feeding the acrd 
directly into the PC SD reader.

It is also important to note that ext is faster than FAT (benchmark, 
anyone?) but, most importantly, it supports permissions, which FAT 
doesn't. Of course, since FR is in general a single user device, the 
permissions might be not so important. Another advantage of ext2/3 is 
linking support, which, for instance, if you are storing maps and you 
have blank tiles files, you can keep a think blank file and have all the 
others be just a link to this one (you would need a script for that to 
make it practical)

What about file systems like jffs2 and ubifs, which are aware of flash 
card wearing?

SD cards, according to SanDisk specs, should have wear leveling logic, 
which controls the number of writes and remaps blocks as needed. 
Wear-aware file systems might actually play against the logic of the 
card and are usually not recommendable.