Fixed the SPIFFS size calculation.

[slaff]

Closes #1313.

[slaff]

@jonnykl Please, check this PR and tell me if it is working for you.

[jonnykl]

This is not correct (see PR 1313)

[jonnykl]

As you can see (here) I also did the same change but in conjunction with the change in line 67 (which is the fix of the bug).

[jonnykl]

Except the change I commented a few minutes ago everything is correct but does not solve the problem. You prevent the developer from using illegal values which is good but anyways the function spiffs_format_internal() erases the sectors for SpifFS and one sector after the end of SpifFS. E.g. if SPIFF_SIZE is set to the maximum allowed value, the sector where esp_init_data_default.bin is flashed will be erased.

[jonnykl]

The fix works now if cfg->phys_addr and cfg->phys_size is a multiple of the physical block size.

Pro (for this fix):

• almost all of the space requested is used ("almost" because SpifFS is organized in logical blocks, e.g. if logical block size would be 5 and the request space is 13, then only 2 logical blocks / 10 bytes would be used)

Con:

• data which does not belong do SpifFS may be deleted

This fix is OK, but this behavior should be documented (bytes from cfg->phys_addr + cfg->phys_size (inclusive) to the end of the physical block will be erased when spiffs_format_internal() is called).

Pro (my fix):

• no other data which does not belong to SpifFS is deleted

Con:

• less space than requested is used (if requested space is not of multiple of physical block size)

I think both versions of the fix are OK. They only differ if the developer specifies a offset/size that the FS does not fit exactly in physical blocks.

[jonnykl]

I think the following code would be better:

cfg.phys_addr -= cfg.phys_addr % INTERNAL_FLASH_SECTOR_SIZE;