Some suggestions for documents

[MouriNaruto]

I found maybe LittleFS's specification and design documents lacks some information when I tried to implement the lightweight read-only LittleFS implementation for some lightweight scenarios like boot from MBR, handler for archivers, and etc.

For example, we don't know the maximum LittleFS volume size for current LittleFS implementation. Maybe is a number which near the 2^64 bytes if block size and block count are 0xFFFFFFFF. But I don't think it's a correctly value in current implementation. So, I open an issue.

Current we know the maximum file size for current implementation from the header file should about 2GiB. But I think that should also be mentioned in the documents. (Maximum file name and attribute length should also be mentioned in the documents too.)

Kenji Mouri

[geky]

It's worth mentioning littefs can be compiled readonly (-DLFS_READONLY), in case that covers your use case.

But you're right these limits could be better documented. One concern is these limits are not well tested, are tricky to test, and historically prone to subtlety, so I'm hesitant to document exact limits until we actually test said limits.

littlefs uses signed block addresses/offsets in several parts of the code to mux with negative error codes, so I think a safer limit would be 2^62 (2^31 blocks_count x 2^31 block_size). If this seems lackadaisical, keep in mind littlefs currently runs into severe performance issues before this point. 2^62 bytes, i.e. 4612 PiBs, is way beyond what most users care about anyways.