newRPL: [UPDATED April 27-2017] Firmware for testing available for download

[matthiaspaul]

(07-28-2016 02:52 AM)Claudio L. Wrote:  The idea behind the initial scan was to find the largest pool of free clusters, and keep not only the cluster, but how many we have available until we need to scan for the next hole.
Being the largest hole in the disk, unless the disk is filled near capacity, or fragmented beyond hope, it's unlikely you'll run out of them. This means you only need to read the FAT table at mount, and hopefully never again for a long time.

That's fine, but on a not too fragmented filesystem the pointer in the FS info sector will likely point to (if the pointer is outdated: shortly before) the same location or at least be near the start of a larger free area (with fragmentation: not necessarily the largest one, though).
It will do so not by some unexplainable "magic", but just because this is an "artefact" of the allocation strategy used by DOS and Windows (and likely most other implementations using the FS info sector) almost always increasing the pointer until it wraps around (in order to increase the timespan and likelihood that deleted files can be undeleted later on - and also for some "high-level" wear-leveling).

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).

Of course, these assumptions don't work for highly fragmented volumes, there isn't much that could be done about it except for performing some form of defragmentation every once in a while.
(I am aware of strategies to still maintain acceptable speed even on significantly fragmented volumes, but they aren't suited for embedded systems as they require a considerable more complicated in-memory representation of the mounted filesystem than the on-disk FAT structures.)

(07-28-2016 02:52 AM)Claudio L. Wrote:  

(07-27-2016 08:56 PM)matthiaspaul Wrote:  At least this is what I would propose as it is easy to implement (almost no memory and code overhead) and it can speed up things considerably if the values are (almost) valid, and does not cause actual problems, if they are not.

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).

Well, if you prefer to let the filesystem work more locally and don't like the idea of increasing the pointer until it wraps around, you could still try some mixed approach to get rid of the initial delay:

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.

Greetings,

Matthias