Filesystems

snipped-for-privacy@lntinfotech.com =D0=BD=D0=B0=D0=BF=D0=B8=D1=81=D0=B0:

this is snip from Microsoft web site which could explain why peoples don't like to use FAT in embedded systems:

"Pricing for this license is $0.25 per unit with a cap on total royalties of $250,000 per licensee. Pricing for other device types can be negotiated with Microsoft. "

so you have to pay to Microsoft $250K to use the notorious FAT file system in your embedded device

Best regards Tsvetan

--
PCB prototypes for $26 at http://run.to/pcb (http://www.olimex.com/pcb)
PCB any volume assembly (http://www.olimex.com/pcb/protoa.html)
Development boards for ARM, AVR, PIC, MAXQ2000 and MSP430
(http://www.olimex.com/dev)

There are also technical reasons why not use FAT32 - basically, FAT was concepted for floppy disks, the FAT gets really too fat for bigger devices. Filesystems which use a bit per allocated cluster will always be 32 times more efficient at space allocation than FAT32 is - simple arithmetics ..:-) .

Dimiter

------------------------------------------------------ Dimiter Popoff Transgalactic Instruments

------------------------------------------------------

snipped-for-privacy@my-deja.com wrote:

None. The "embedded world" is too wide for all of it to be covered by a single filesystem.

What makes you assume you can't?

Because sometimes simple is more important than feature completeness.

--
Hans-Bernhard Broeker (broeker@physik.rwth-aachen.de)
Even if all the snow were burnt, ashes would remain.

If you mean is there a standard system that everyone uses then I don't believe there is. I don't think there's a standard _anything_ everyone uses :-)

You can. Try

as a good free one that handles FAT32. I don't think it will do ext2fs but then I haven't looked too hard because that is of no use to me - some flavour of embedded Linux will certainly fit the bill. Lewin also has DOSFS on his website that should have worked well but I never managed to get to work. EFSL did work pretty much straight away but you have to make sure you allocate your own buffer space explicitly because if you use its own allocation methods it will infuriatingly eat up just one of your pretty GUI pictures and leave all the others alone despite have oodles of RAM to play in. Took me ages to find :-<

The only time my system uses a filesystem is to program the flash in-field with new code taken from a memory card. If I had the time or inclination I would have a bootloader based around the filesystem which would live at the start of flash and then copy code in after it. It wouldn't need to replace itself and would guarantee that the system would boot even if the reprogram failed. The rest of the program would have no knowledge of files and reprogramming.

Some people may use a filesystem to boot from some removable medium which gives them a variety of benefits, depending on their application. A PC with only a floppy drive springs to mind.

Horses for courses. Some people might just want something that will open a file on an SD card whereas others may want to control multiple hard-drives and transfer data as quickly as possible. All I do is read a program file from an MMC card and so I have no need for the file system to create/rename/delete directories and files or mount multiple partitions and all it's caching trickery is of little use as well.

It's a debunked patent assertion that, in any case, relates only to LFN support. I challenge you to point to a single licensee who is paying these fees, BTW.

... and this isn't true either, you have to pay a MAXIMUM LIFETIME amount of $250K. If you ship anything les than 1,000,000 units of product containing patent-covered code, you pay less than 250K. If you ship 100 units, you pay $25.00.

That's beyond simple; it's naive. No file system can make do with a single bit per cluster, because that's just enough to cover one aspect of what a filesystem must do: free space book-keeping. The other information (cluster sequence forming a file, directories, file attributes, ...) are what cause most of a file system's "overhead".

Yes, FAT has serious shortcomings. But raw size of book-keeping data is not really one of them.

--
Hans-Bernhard Broeker (broeker@physik.rwth-aachen.de)
Even if all the snow were burnt, ashes would remain.

Thx for ur replies, Further, what is so special in TFS that it is used for booting alone in many embedded projects ? Further, i find some projects using mulitple filesystems . But, wht is actual the advantage in doing so ?

I would like to have many technical reasons.

Thx in advans, Karthik Balaguru

I agree to your points.... But, i find some using multiple filesystems in the same embedded project. But what is the necessity ? Are there projects that use more than 2 filesystems ?

I find, That is, 1 filesystem for Booting, 1 filesystem for storage, 1 filesystem for execution etc .. , But why and How ???

How does Filesystem play such an important role to have some many filesystems for different modules ?

What characteristics of Filesystem determine it to be suitable for either Booting or Storage or Execution ? How is the selection being done for this ?

Which is the best filesystem for Booting ? And similary which is best for Storage and the best filesystem for Execution ?

Some more ellaborative info plz,

Thx in advans, karthik balaguru

Arithmetics is naive indeed, but it has the advantage of giving us predictable and repeatable results. BTW, did you notice that I was referring exactly to space allocation quite explicitly? Those who have written at least one OS with a filesystem will undoubtedly know this is where practically all the filesystem related overhead goes. You can save some of the overhead by making something MS-stylish, i.e. you will have to "defragment" the disk all the time, but this is hardly what I would call an OS...

Dimiter

------------------------------------------------------ Dimiter Popoff Transgalactic Instruments

------------------------------------------------------

Hans-Bernhard Broeker wrote:

I didn't quite understand you, if you use the FAT filesystem in a commercial product you must pay royalties?! But loads of MP3 players and the like use that file system for internal storage. I would expect if Microsoft demanded that kind of money, no name MP3 players would not be as prolific as they are now. .

-Isaac

Ask the person who you found to be doing that.

A booting filesystem needs to be simple.

A data-storage filesystem needs to be robust when written to.

A read-only filesystem for code doesn't need to be written to.

Speed, efficiency, tolerance for power-off during writes, etc.

Tht depends on what you're booting and how you're booting it.

That depends on the requirements.

--
Grant Edwards                   grante             Yow!  Did I SELL OUT yet??
                                  at               
                               visi.com

The jury is still out on this:

Finally, on January 10, 2006, the Patent Office ruled that features of Microsoft's implementation of the FAT system were "novel and non-obvious" reversing both earlier non-final decisions.

licensing

I still challenge you to point to a single licensee.

The reason for all this is very simple: Microsoft wants to be seen as an embedded solutions provider. Almost nobody uses their products. They want to be able to say that "their" IP is in XYZ number of devices.

Leaving aside the FAT32 issues if your file system is on flash then there are some reasons you may not want to use ext2. The problem is that flash wears out much faster than rotating magnetic storage so you want to minimise the number of times you write to it.

Therefore:

1) There should be no swap

2) /tmp and parts of /var should be in RAM using tmpfs

3) Everything else should be on a flash device possibly using ext2 or better still a specialist flash file system such as JFFS2

-p

--
 "What goes up must come down, ask any system administrator"
--------------------------------------------------------------------

Just one more hint: if using ext2/ext3, use the "noatime" option on mount. Otherwise write accesses to the device will occur even when files are read (to update the access time entry).

Rob

-- Robert Kaiser email: rkaiser AT sysgo DOT com SYSGO AG

Klein-Winternheim / Germany

^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ BTW, this latter requirement affects not only the choice of filesystem but also the choice of storage media: especially compact flash devices can apparently suffer damage if power is lost while a write access is in progress. No filesystem can compensate for that...

Rob

-- Robert Kaiser email: rkaiser AT sysgo DOT com SYSGO AG

Klein-Winternheim / Germany

Of course you use different file systems for different purposes, just like you use different components for different purposes. As an example, and embedded linux system might use:

cramfs for rarely changed code storage (maybe for /usr)

ext2 for an ram disk image for /, allowing read-write access

tmpfs for /tmp, allowing low-overhead temp files

jffs2 for /home, giving read-write access optimised for flash

reiserfs3 for an external microdrive (miniature hard disk), for fast and efficient journalled hard disk files.

fat32 for external cfdisk devices

Having failed to track down whre EFSL is leaking to destroy my GUI then I am ready to try a new filesystem. Lewin, I've had a go with DOSFS and supplied it hardware drivers that worked under EFSL but it just does not seem to work. Obtaining the volume information just returns gibberish. I'm following the method shown in the examples but nothing seems to be forthcoming.

Can anyone suggest any other small simple filesystem that might be worth a try. Someone suggested RDCF2 but it seems a bit over complex for what I want. I'd better give it a try though becuase I'm running out of options.