Post Reply 
newRPL: [UPDATED April 27-2017] Firmware for testing available for download
07-28-2016, 02:54 PM
Post: #353
RE: newRPL: [UPDATED July-25-16] Firmware for testing available for download
(07-28-2016 10:36 AM)matthiaspaul Wrote:  So, by taking advantage of the FS info sector, you can skip the initial scan (or, if the pointer was outdated, reduce it to a very short scan until it is back in "sync"), and likely still don't have to read the FAT for some long while afterwards (until the medium gets full or fragmented).
(07-28-2016 02:52 AM)Claudio L. Wrote:  It would speed up mounting, but slow down actual use, as the FAT table would have to be read more often than with the current implementation. In other words, it would spread out those initial 7 seconds into every single write operation.
That's overly pessimistic, as this would happen only on a fragmented or nearly full volume (see above).
We are thinking of two different strategies. My strategy is to know the start and extent of the "hole", your strategy is to know the start of the hole, but not the end.
If/when my strategy finds a large hole, it doesn't need to verify if the cluster is free each time it needs to allocate clusters (unless you run out of them, in that case it scans for the next hole).
Your strategy gets the next free cluster (or last used, same thing), but each time you need to allocate a new cluster, you need to go and check if the next cluster is actually free by reading the FAT.

That's why you say "short scan", and you are correct, as with your strategy you only need to "walk" a few clusters until you find a free one. With my strategy, the scan is not so short, because even if you quickly find the next hole, a big hole requires you to read potentially almost the whole FAT to determine its size. But once you find a big one, there's no need to check ever again (until you run out, that is).
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.

Even if I adopt the next cluster hint from the BPB, I'd still need to know the size of the hole, which potentially requires a large chunk of the FAT to be scanned (if it's a big hole), so with my strategy in mind, there's no big advantage in using the hint.

Perhaps the "best of both worlds" would be:
a) Use the hint of the BPB as a start point, scan from there until the next hole only (don't look for the largest).
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.
c) Add all the logic to write the BPB dirty bit when the first file is open, and write it again when the last file is closed.

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.

(07-28-2016 10:36 AM)matthiaspaul Wrote:  Use the FS info sector only on volumes beyond a certain size threshold (when the delay starts "hurting" the user) and ignore it on smaller volumes.

This is a good idea, although my proposed "compromise" idea above I think defines a single threshold that performs the same on big or small volumes.

I should start working on these changes (unless you see something fundamentally wrong with my approach above).
And hey, thanks a lot for the high-technical-level discussion, I appreciate deep digging like this, as it always leads to better implementations.

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 - Claudio L. - 07-28-2016 02:54 PM

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