SD card filesystems for bare-iron use

Am 09.04.2010 05:15, schrieb Stuart Longland:

BSD also supports EXT2, and you are allowed to use it. Get the OpenBSD sources and look in sys/ufs/ext2fs.

That must be a specific problem of your FAT module. Long file names are stored in a way that programs that don't talk long file names skip them automatically.

I'm not a patent lawyer, but as far as I know, all those patents only apply to Microsoft's "common namespace" of short and long names. My implementation doesn't have a common namespace. A file has one name, and that's it. Period.

Instead of switching over everything, have you considered using another FAT implementation? I hear there are a few around, and making your own doesn't take too much time. At least, if implementing your own ext2 is an option, implementing your own FAT should be a better one because it's simpler. Mine took a week or so.

Stefan

That certainly does look like a good option. I was under the impression that some of the BSD code for EXT2 was GPL-licensed due to comments that it would "taint" the kernel with GPL code... but I'll admit I was not looking particularly hard.

I'll have a closer look.

Indeed... I'm having difficulties getting FatFS to behave in this regard. The documentation takes a bit of getting used to, and thus far I have not succeeded in getting long filenames to work.

It's the common namespace that seems to be giving me the most trouble. Windows XP will use this by default. Linux is switchable between namespaces, and thus I can easily control which namespace I am looking at, but Windows seems to assume all systems can see both.

The upshot being that I have difficulty locating files on the embedded system, that have been placed there by a Windows XP system.

There are other issues with FAT, that don't affect this project, but might affect others in the future. I'm raising the question here however since I know it's been a major bugbear of a lot of projects; since FAT16 doesn't really cater for modern requirements.

Implementing a FAT driver from scratch is certainly a possibility. For what it's worth, I've got the time to implement neither FS ... this would be a personal persuit in my spare time.

I saw another implementation, EFSL (linked to earlier), which seemed a lot cleaner than FatFS and provided provisions for separate filesystems (although only implements FAT at this stage). Not sure what its status is these days. I attempted to port it across to Luminary Micro, using StellarisWare as a backend for the SPI driver, but I had trouble getting it to link. A bit more tinkering is in order... and I think the Makefiles could do with a cleanup too to aid portability.

I haven't gone looking for many other FAT implementations, partially because I believe FAT really needs to give way to something more modern. A tough ask when so much of the world is addicted to a certain Redmond-developed OS, but a transition that needs to happen nonetheless IMO.

The Windows API always gives you two file names, a short one and a long one. This is what I understand as "common namespace". Try 'dir /x' for example. Linux can be configured to ignore long file names (by mounting as 'msdos') or to prefer them (by mounting as 'vfat'). However, when mounting as 'vfat', you can still access files using their 8.3 alias. You don't see those in 'ls' output, but I recall there is some special call to convert a long file name into a short one, implemented for Samba.

I see no reason why one would need *that* in an embedded file system. Mine ignores short names completely if there are long ones, and fills short ones with random junk when creating them (I tried leaving them blank, but then Windows refuses to read the files). So there's no common namespace - just an ignored field next to other ignored fields such as "creation time".

One implementation that I had briefly looked at was this one , but it's GPL'd.

Well, being nitpicky, you don't have any option other than FAT for SD cards, because that's what the SD 2.0 spec requires. And the "more modern" thing for SDXC cards goes by the name exFAT, which seems to be nothing more than FAT with some more bells and whistles (a coworker converted my FAT interpreter into an exFAT interpreter within days). Of course using another file system works as long as you don't expect other consumer devices to be able to read it, but I would expect that at least some card controllers optimize upon the assumption of containing FAT (such as, giving the often-changing FAT more wear leveling room than the data area).

Stefan

This is most interesting... not doubting what you're saying of course, but I would have thought the SD standards would have dictated the protocol interface for storing filesystem blocks on the card, and left higher level things like filesystems to the end user. FAT being used of course because it is a lowest common denominator standard.

As for exFAT... not sure what the support is for that FS. The thing I'm very conscious of though, is that most (if not all) FAT-based filesystems are hamstrung by the fact that they're trying to "bolt-on" features to a legacy filesystem which was never intended to implement these features. It just seems a bit of a hack to me. (Then again, EXT[234] has its share of hacks I suppose.)

The point is interchange: everything that says "I support SD cards" has to support FAT, so consumers can be sure they can transfer their data from here to there using an SD card. Of course, if you control both ends, you're free to do whatever you want.

Stefan