Post Reply 
newRPL: [UPDATED April 27-2017] Firmware for testing available for download
07-30-2016, 01:26 PM
Post: #355
RE: newRPL: [UPDATED July-25-16] Firmware for testing available for download
(07-28-2016 02:54 PM)Claudio L. Wrote:  Being an embedded system where we don't have any read cache for the FAT, just having to read one sector to check if the next cluster is free every time a new cluster is needed is quite a slowdown.
[...]
b) Determine the size of the hole, but up to a limit of let's say 1024 clusters. On FAT32 it means we'd read 8 sectors max. during this limited scan. If the hole is bigger it doesn't matter, as the next scan will find the next 1024 clusters of it with another "short scan" of 8 sectors.
[...]
This would reduce the initial scan time (not as much as you were suggesting, but a lot) and the penalty introduced by having to check the next cluster will happen only every 1024 allocations instead of every time. I think it balances both strategies quite well.
Do you read the FAT on a sector by sector basis or in larger chunks (depending on how much memory is available)? If you do it on a sector by sector basis, perhaps the best compromise would be to look ahead cluster entries worth one sector only: One sector gets read anyway. Consequently, as the info is readily available in the buffer, it makes sense to evaluate it before the buffer is trashed and the same sector would have to be read again later on when searching for the next free cluster. Reading ahead 8 sectors could speed up things some more if you do multi-sector-I/O and have a buffer large enough to hold 8 sectors, but the gain won't be that large any more and looking ahead always carries the risk that the stuff isn't needed at all. In the worst case, you would have read 7 sectors for nothing.

Assuming a sector size of 512 bytes (although this isn't fixed), this would be 128 clusters for FAT32, 256 clusters for FAT16, and ca. 340 clusters on FAT12. This may be more than enough already. Combining this with the cluster size, this would cover file growths of 64 KB and more already, so anything more might be overkill on a calculator.

Greetings,

Matthias


--
"Programs are poems for computers."
Find all posts by this user
Quote this message in a reply
Post Reply 


Messages In This Thread
RE: newRPL: [UPDATED July-25-16] Firmware for testing available for download - matthiaspaul - 07-30-2016 01:26 PM



User(s) browsing this thread: 2 Guest(s)