Shrink root dir size for tiny (<=128K) FAT12 fs

[eightycc]

Reduce the size of the root directory for a FAT12 filesystem on a tiny (<=128KB) flash device.

When oofatfs creates a filesystem it uses a default root directory size of 512. For most flash devices this is a reasonable choice, but for tiny flash devices this can consume a large portion of the flash. For example, a Trinket M0 has a 64KB filesystem of which 16KB is consumed by the FAT12 root directory.

This pull causes f_mkfs() to automatically reduce the FAT12 root directory from 512 entries to 64 entries when it detects a device <= 128KB. For the Trinket M0 case, the root directory flash size usage is reduced from 16KB to 2KB.

This pull will reduce the number of files and sub-directories that can be placed in the root directory from 256 to 32. Files and sub-directories usually take 2 entries due to LFN (Long File Name) support. The number of files and sub-directories that can be stored in sub-directories are not limited by this change due to FAT12 allocating them dynamically from the filesystem's data space.

This pull will not affect an existing filesystem. Only when the device is reformatted will the root directory size be reduced.

For background, Linux's mkfs.msdos has a command line option that sets the root directory size.

This pull has been tested on Linux (Ubuntu 22.04), Windows 10, and MacOS Big Sur (11.7.8).

[dhalbert]

How much space is saved if the limit is 64 entries rather than 32? I guess it uses 4kB for the root, so leaving 60kB, which I think would still be fine. @ladyada was concerned that 32 files (or 16 files if long files names) is really too low.

[eightycc]

It takes two entries per file or sub-directory, so I set it to 64 entries in the pull giving 32 files or sub-directories in the root directory. Each entry is 32 bytes, so every additional 16 entries takes another 512 byte sector.

As the pull is, root directory capacity is 32 long name files or sub-directories. I upped it to 64 entries because I had second thoughts, too.

I probably shouldn't overthink this, but modifying oofatfs/ff.c doesn't leave me completely comfortable. It's fragile code, so any changes are a risk. Also, changes complicate incorporating upstream fixes at a future date. On the other hand, this isn't the first CircuitPython mod to oofatfs.

[dhalbert]

Here I've annotated the changes more, and also increased the number of entries to 128, since we have use cases for more files in the root directory.

[dhalbert]

probably shouldn't overthink this, but modifying oofatfs/ff.c doesn't leave me completely comfortable. It's fragile code, so any changes are a risk. Also, changes complicate incorporating upstream fixes at a future date. On the other hand, this isn't the first CircuitPython mod to oofatfs.

As long as the changes are clearly annotated as // CIRCUITPY-CHANGE (as I did in the review), I think it's OK. The main thing is to make it easy to spot and understand the changes from upstream.

[dhalbert]

@tannewt I want to run this by you too.

[eightycc]

@dhalbert CI fail moved to another SiLabs board. It looks like timing:

Slcp parse warnings for /home/runner/work/circuitpython/circuitpython/ports/silabs/circuitpython_efr32.slcp
	Referenced SDK Extension 'cp_efr32:1.0.0' could not be found.
Warnings loading project: 
 - Referenced SDK Extension 'cp_efr32:1.0.0' could not be found.

This warning appears only for the failing targets.

Perhaps the silabs/cp_efr32_extension path isn't getting signed in time for another parallel make? Signing should happen in the slc-generate target in silabs/Makefile.

[tannewt]

@dhalbert CI fail moved to another SiLabs board.

I just reran the test and it worked ok. Makefile race condition seems likely.

[tannewt]

This is fine with me! Thanks for the investigation!

[dhalbert]

Thanks for this great work!