Hello,
We are working on a project that is using the Larwe DOSFS 1.03 library, over an SD/MMC card in a standalone embedded platform. I have implemented a generic buffer cache between DOSFS and the physical media, which works well and gives the expected performance improvements.
The access pattern in this application is typically just sequential writes of ~3MB files. However, we've found a very strange behaviour, whereby DOSFS will only allow us to write as many files to the disk as were present when the system was initialised.
For example, if we pre-populate the filesystem with files foo1, foo2, and foo3, then start up our app and attempt to write foo1, foo2, foo3 and foo4 in that sequence, we end up with
foo1, foo2, foo4
on the disk. foo3 exists after it is first written, but then foo4 "replaces it". The clusters of foo3 are still allocated, but it has no directory entry.
It's alomst as though DOSFS is refusing to expand the root directory beyond the unmber of entries that existed there in the first place.
Has anybody seen anything like this, or have any pointers on where to start looking for the problem? We see this behaviour with or without our caching enabled.
Secondly, more of a comment / suggestion - I found that the file write time increased linearly with the number of allocated clusters on the disk. I traced this down to the linear, start-from-the-beginning search in DFS_GetFreeFAT().
for (i = 2; i < volinfo->numclusters; i++) { result = DFS_GetFAT(...) ... }
As the number of allocated clusters grows, so will this search time. I did a little hack whereby we remember the cluster of the previous free FAT, and start our search from there next time. This seems to work nicely, and completely "levels out" the write time for these successive file writes.
Can anybody confirm if this will do invalid things to the disk like leaving holes in the FAT, if there are file deletes in between writes? I wrap the starting point around if it reaches volinfo->numclusters, so those holes should be filled eventually.
Running fsck.msdos on the resulting file systems doesn't report any nasties.
There doesn't seem to be any link betwen this optimisation and the problem I describe above - it occurs regardless.
Thanks for any comments or suggestions,
John