FullFAT 1.0.0 (RTM) Released

Finally FullFAT 1.0.0 is out of the door. The RTM package is now available, this includes the completed source-code of the initial stable release. A new (FINAL) release will be available in the coming weeks, this will contain the same source-code, only with updated drivers (as sent to us by developers out in the wild), as well as updated demos for Linux, and stdio integration.

FullFAT Embedded FAT Driver (FAT 12/16/32) 1.0.0

FullFAT is a high performance, thread-safe, FAT filesystem implementation for embedded systems. It aims to be the best open-source FAT filesystem library available. The 1.0.0 release achieves this substantially, by providing a complete API, true thread-safety, and 100% compatibility on all true ANSI-C compilers.

See http://www.fullfat-fs.co.uk/ for more information.

For technical details, support and API documentation see http://wiki.fullfat-fs.co.uk/.

Download now.

Posted in General Discussion | 3 Comments »

Announcing EFS (Embedded Future Storage)

FullFAT is almost out of the door now, and there’s one thing I learnt from implementing the FAT File-system, its not a very clean design or particularly good at dealing with large numbers of files within a directory.

Talking about file-systems, Microsoft have recently started touting their EXFat filesystem which is essentially Fat64. There’s just one problem with it, the specifications are not open, and Microsoft holds patents and right to that too. We need a completely public domain, simple to implement, unambiguous and stable file-system for all the media devices that currently exist.

Thats why, as of today I am announcing a new file-system. Its designed to be computationally simple, (ideal for embedded devices) and well structured allowing fast traversal through large directories. The design is not based on FAT in any way, and is built from the ground up using ideas I learnt from writing FullFAT.

The actual file-system itself is a specification, however I am also providing a reference implementation in the public domain. I shall also try to write Linux and Windows integration drivers, and lobby the file-system around as much as possible to get wide support for it.

The specification also recommends a special partitioning scheme including a small FAT12 partition to hold drivers for the most common platforms, until the FS is adopted more widely.

The following are just a few of the key-points my file-system aims to achieve:

• High Performance Read and Write.
• Computationally Simple to handle.
• Large File Support (64-bit filesize field – Theoretical maximum size is 8192 Petabyte file).
• Large Volume Support (Supports all block-sizes of 512 multiples) (1TB with 512 Block size, 2TB with 1024, 4TB with 2048, 8TB with 4096, 16TB with 8192 block sizes).
• Really Fast Directory Traversal – Special Directory structure organises objects more efficiently for reading and writing.
• Really Fast Freespace allocation – A very small and tight free-space bitmap is used to designate free space in terms of clusters.
• Varying Cluster sizes. (From blocksize to 2MB cluster size is specifiable – 512byte multiples of course).
• BlockChains – These are linked lists of blocks within allocated clusters. They are primarily used for chains of directory data and file meta-data as well as file data maps.
• File-data maps, these are like the FAT tables in FAT except the pointers are compressed into extents. They are variably sized cluster addresses describing the chain of clusters making up a single file. Standard size is 32-bits, per-cluster address. However a 64-bit address length can be specified (allowing compatibility with future storage mediums). 32-bits is enough to address 2TB with a cluster size of atleast 1024 bytes.
• Fragmentation is reduced through algorithms acting on the free-space bitmap.
• All data structures are 4-byte aligned, sizes are multiples of 4, and can never cross sector boundaries. (Thus helping reduce computational complexities).
• UTF-8 Filenames – 1024 Bytes used for name storage, that is upto 1024 char names, or 256 32-bit unicode charachters.

It would be nice to get the EFS specification out there, and really get it adopted, however I am also aware that such a task is not easy, one only has to look at the OGG Vorbis project to know that. Perhaps this design will only serve as a good educational tool, but it would be also great to get it widely adopted. I shall keep this blog updated as I go through the design process. I would also like to encourage others to suggest or help in the design phase. There are many ideas I have, but maybe there are much nicer ways of doing things.

For more information you may email me. (EFS doesn’t exist yet I’m still working on my reference and design blueprints).

James

Posted in General Discussion | 2 Comments »

FullFAT 0.97B (Release Candidate 2) Download Now Available

FullFAT Release Candidate 2 is now available from the googlecode page (http://fullfat.googlecode.com/).

This is a pre-1.0 release, and includes a snapshot of the current SVN also including the FFTerm project for the Visual Studio Demo. This is a more refined BETA than the previous, and has the following new features:

• Path Cache – much faster access to files while doing repeated operations. (Wild-card copying).
• Date and Time support.
• Append File Mode support.
• FF_Open() now uses simple mode flags.
• FF_GetModeBits?() function converts fopen() style mode strings to the appropriate flags.
• Public API now has consistent ERROR types. (FF_ERROR) = (FF_T_SINT32).
• Much improved demo with MD5 check, wildcard copying, remove command.

I’m now testing FullFAT thoroughly, if anyone can help please get in touch (www.worm.me.uk/contact/). I’m also spending time writing comprehensive documentation, although this may take a couple of weeks. So I estimate an official 1.0 release for end of July.

The MinOS complete integration demo is now coming along nicely. This will be provided as a separate demo for the 1.0 release as a separate download (registration required).

MinOS is my commercial embedded operating system, its currently in the early stages, it currently provides portable API’s for Block, Stream and Audio devices.

James

Posted in General Discussion | No Comments »