The point of FullFAT is to be faster compared to other open-source drivers that are designed for embedded systems. FullFAT alone will never be as fast as a fully featured Linux system. Thats because Linux systems always have large amounts of memory to index the entire directory structures into a special tree. They also populate HASH table index’s to make file lookups really fast.

Plus linux has a really big caching system that speeds up disk access a lot.

FullFAT enables some of these features for systems that have a bit of memory.

FullFAT is still being integrated into ReactOS, and so very soon we’ll have a Windows driver based on FullFAT which can directly replace Microsoft’s own driver. When this is complete, I shall be interested to do some performance comparisons.

James

Then you can compare load times of ubuntu in fat and ubuntu in fullfat? you may want to contact linux developers…

Also you may wish to try the same with efs.

The fullFAT driver tries to access non-existing sectors, thus making an application hang:

This function:

FF_FindFreeCluster(FF_IOMAN *pIoman)

might return a cluster which is not physically present, shouldn’t is check pIoman->pPartition->NumClusters ?

The same for :
FF_T_UINT32 FF_CountFreeClusters(FF_IOMAN *pIoman)

It may return a cluster count higher than NumClusters, thus showing a “Free Space” of more than 100%

Regards,

Hein

In FF_UnlinkClusterChain()

why isn’t pIoman->pPartition->LastFreeCluster updated?

Problem is that when the disk has been full, I still can’t create new files after removing others

Hein

I found a problem in FF_MountPartition:

if ((pPart->BlkSize % 512) == 0 && pPart->BlkSize > 0) {
// Volume is not partitioned (MBR Found)
pPart->BeginLBA = 0;
} else {

On some sdcard with partitions, BlkSize happens to be a multiple of 512 and the volume doesn’t mount

Otherwise, good work! I tried it on a UC3 (Atmel AVR)

Kind regards,

Hein Tibosch

James

I’m already in contact with Fireball, so we can clarify this issue.

James

If you get the releases directly it comes with FFTerm so you can build the Windows 32 demo easily.

Otherwise get the latest ffterm from ffterm.googlecode.com, there should be the FFTerm and FullFAT directories next to each other, to allow building.

joolz

joolz

However, I’ve noticed that FullFAT is released under GPLv3, whereas ReactOS is under GPLv2+, so there may be a potential GPL violation if we were to include this in our source tree. Could you perhaps make yourself known to the devs at #reactos on FreeNode IRC? Suppose Fireball would be able to discuss any resolution of the matter and could also use your advice on using the FullFAT lib. Thanks.

The original discussion is found at http://www.reactos.org/forum/viewtopic.php?f=14&t=7279

Please move function FF_DetermineFatType to the begin of FF_MountPartition.
Because if the partion is not FAT, there was a crash in
pPart->RootDirSectors = ((FF_getShort(pBuffer->pBuffer, FF_FAT_ROOT_ENTRY_COUNT) * 32) + pPart->BlkSize – 1) / pPart->BlkSize;
because pPart->BlkSize is zero.

greetings
Johann

James

I’m about half-way through writing it now, and I’ll be releasing my latest code to the Google code SVN shortly.

Any timeplan for release FullFAT ?

Any plan to add exFAT ?

Thanks for information.

greetings
Johann Obermayr

I’m constantly optimising my work in these areas, checking memory footprint etc.

It will be very small.

FullFAT in its current state can utilise very little memory, or as much as can be made available to it.

There’s a tiny memory manager, which handles buffers in a thread-safe way, the minimum memory this uses is 512 bytes, (1 block). Although I’m not too sure how it will perform with such a constraint.

I shall add more details as soon as I can. Take a look around February for a release.

That said, when released, it will be of high quality, secure, stable, portable, thread-safe, and of high performance.

It’s taking me a while to think about some design decisions, and I’m constantly simplifying what I have so far.