Metadata can't be compacted below block_size/2 ? about littlefs HOT 2 OPEN

I've removed the open/close/open as I found out it was created by someone before me in the project due to a bug they had elsewhere... (Did you know that some OS'es allow you to free a memory chunk allocated from a memory slab not part of the slab you are free-ing to? This leads to hilarious results, especially if a different thread later receives the chunk as a result of their allocation from the slab!)
Now I just sync() after header to get some ID into the file (inline) in case I need to search for it in the raw blocks later.

from littlefs.

Hmmm, this gets tricky.

The thing we really don't want to do is compact a metadata block that doesn't benefit from compaction (is only a single commit).

The block_size/2 limit is the threshold where we split a metadata block, so after compaction all metadata blocks should fit in block_size/2. Using this also as the lower-bound for lfs_fs_gc means that we are always guaranteed to make progress if we attempt a compaction.

Some options:

1. Make the block_size/2 limit configurable (split_thresh?).

   This would let you tweak the worst-case compaction size. Though a lower split_thresh would result in more mdirs/lower mdir util.

2. Explicitly count the number of commits (we currently don't track this), and allow compact_thresh < block_size/2 iff commits > 1.

   This would allow opportunistic compactions, but I'm not sure opportunistic compactions are that common when the metadata/block_size ratio isn't so high.

As a workaround, you could also try increasing block_size. The larger the block_size, the more space there is for the log to append to. Though I realize this may make other performance issues significantly worse...

This may also be exacerbated by the way I create files as I open+create the file, then close it again and re-open before starting to write.

You can call lfs_file_sync in this case. It won't save any progs/erases, but it will avoid an extra path lookup.

from littlefs.