Minimal block_size

[jrast]

What is the minimal block size? With 32 byte formatting fails (Error -28, No space left on device), with 64 byte formatting and read/write files worked in my short testcase. Is 64 Byte the minimum?

[geky]

Short answer: 128 bytes

Long answer: The data structure for files can use at most this many bytes:

For w = 32-bits, our minimum block size is 104 bytes. Rounding to 128 bytes gives us a bit of fudge room if we need to expand data structures in the future.

Though this check should be asserting if your block size is too small. Are you compiling with asserts disabled?
https://github.com/ARMmbed/littlefs/blob/494dd6673d008c03e3199b24af7bff0fe82017f1/lfs.c#L3378-L3380

Maybe I should change the assert to be a bit more explicit and just check against 128...

Out of curiosity, what is the need to make the blocks so small? Smaller blocks will improve metadata access, but unfortunately will also increase the allocator cost.

[jrast]

Short answer: 128 bytes

Maybe the commet for the block_size in the header file should be extended to include this information.

Are the asserts disabled by default? Because I did not change / disable anything. But actually I'm not working on an embedded system but on a python wrapper for littlefs (more on this later).

I used the small block size to see if littlefs would fit our needs on the embedded system. We only have a 8KB external EEPROM and therefore a small block size would be prefered. I once tried littlefs and it was easy to integrate, thats why I'm currently fiddeling around with the project to see how it would behave in our case.

[e107steved]

You might have already got your answers, but here's what I found. I've got a FRAM (actually rather more than 8KB) configured for 128-byte blocks, with 9 files on it. The files and littleFs overhead take 10368 bytes in total. Adding up the size of the files gives 7204 bytes. I reckon that is spread over 58 blocks (7424 bytes) so about 220 bytes 'wasted' due to dead space at the end of files. If my sums are right, that gives 2944 bytes (23 blocks) for LFS overheads. One file is just 13 bytes, so probably stored inline. One file is 5200 bytes, so quite a lot of blocks. The others require 1-5sectors each.
I reckon that's pretty good! (FatFs took about 50KB of overhead, IIRC)
(If I've understood the allocation scheme right, with 128-byte blocks, each file requires two blocks for the duplicated directory entries; so that leaves 5 blocks used for the fixed overhead)

[Igor-Misic]

Maybe I should change the assert to be a bit more explicit and just check against 128...

I would find this more helpful if this was static_assert. The blocksize shall not change in runtime right?

[geky]

Are the asserts disabled by default? Because I did not change / disable anything. But actually I'm not working on an embedded system but on a python wrapper for littlefs (more on this later).

Ah, by default littlefs uses the stdlib's assert: https://cplusplus.com/reference/cassert/assert/.

Depending on your toolchain/build rules asserts may only be enabled in "debug" mode. At the compiler level this is usually controlled with -DNDEBUG (NDEBUG => no asserts). But it's common for build systems to do funky things.

I would find this more helpful if this was static_assert. The blocksize shall not change in runtime right?

This is true in theory, but:

1. The block_size is a runtime variable right now. This should change in #491, but at the moment it's a variable to allow multiple littlefs instances with different block sizes.

   So while conceptually it's a constant, it's not at the compiler level right now.

2. static_assert is uncommon in C projects, so may be unreliable. It wasn't introduced until c11 (littlefs follows c99), and defining it to a noop is an easy way to procrastinate on implementing it in less-conforming compilers.

   Keeping it as a runtime assert has a better chance of being enforced. There is a code cost, but if that's an issue asserts can be disabled.

   Though in a different language a static assert would be the way to go.

[geky]

I've gone ahead and created a PR to make this assert a bit clearer: #802 Let me know if anyone has more thoughts on this.