SPIFFS size is not an integer multiple of block size.

[ABH10]

For some of the boards defined in boards.txt, the allocation for SPIFFS is not an integer multiple of the SPIFFS block size.
For 4MB boards, for example, there is 1MB for PROGMEM, 3052 kB for SPIFFS and 20kB for EEPROM. The block size is 8 kB, but 3052 kB is not divisible by 8 kB blocks.
I propose to modify eagle.flash.4m.ld linker file and boards.txt to use an SPIFFS block size of 4 kB, which works fine.

[me-no-dev]

We need to check if changing block size would make the partition unmountable. I agree otherwise that block size should be 4K.

[ABH10]

I have been using 4 kB block size for some time now. Before switching from 8 kB to 4 kB block size I had all kind of issues. I am working with large files in SPIFFS that are updated often and are opened in multiple file descriptors. Using an SPIFFS size that is a non-integer multiple of block size is not compliant with the mount instructions from Peter Andersson.
When an SPIFFS with 8 kB block size is unmounted and you mount an SPIFFS with 4 kB block size, then the "SPIFFS_USE_MAGIC" feature will not recognize the SPIFFS and the system will be reformatted using the new block size.

[kojagiri1934]

I've confirmed this behaviour causing trouble with OTAs. We have OTAs over 2G (yes!) which work well 95% of the time, the remaining 5% after a couple of retries. The problem is Arduino IDE-based deployments still go out with 8K blocks (though for now using mkspiffs utility for a server-side build reasonably resolves the issue for me).

Minor tweak suggestion for this issue: SPIFFS binary size should be the minimum viable size based upon blocksize 4K + size of actual files required. Currently with 1 file size 2K, it (default) generates 64K files which is unnecessarily large, when 16K should be Ok as per the spec.

[earlephilhower]

This is the kind of problem I saw when using the head MSPIFFS tool. Version 0.2.0 of mkspiffs doesn't check this when passing in the size to the SPIFFS backend, so it silently (probably) rounds down to an integer number of pages.

I don't agree with @ABH10 's suggestion of going to 4K sectors, though, due to the data loss it would cause. I'd recommend that boards.txt.py simply supplies the largest space possible while observing the block size defined.

[devyte]

@earlephilhower @d-a-v If a fix is required that causes current spiffs images to no longer mount and reformat, this should be targeted for 3.0.0.
If this can be fixed and still maintain compat with currently deployed spiffs, then it can be done before 3.0.0.

[earlephilhower]

Absolutely no data loss! Let me dig through the code to see what it's doing now. The only safe thing would be to ignore fractional leftover blocks in mkspiffs, and SPIFFs doesn't seem to be dying a lot, so I think this is just a matter of passing in the right number for pedantry's sake at this point.

[earlephilhower]

SPIFFS will round down the number of blocks it thinks the FS has even if you pass in a non-integer multiple of blocksize due to its integer division in the macro:

https://github.com/pellepl/spiffs/blob/f5e26c4e933189593a71c6b82cda381a7b21e41c/src/spiffs_nucleus.h#L185