Open Johnxjj opened 8 months ago
Hi @Johnxjj, this depends on the size of your file's metadata and is unfortunately not easy to answer.
A file's metadata includes any inlined data, as you mentioned, but also its filename, any custom attributes, a possible skip-list (2 words), a possible move state (3 words), a possible tail pointer (2 words) and some overhead to manage metadata (1 tag per attribute, both custom and filesystem-level, a revision count, a checksum+tag, ~an erased-state checksum+tag~).
It may be more useful to create a test file, and look at the file's metadata log on disk (file's mdir, mdir's blocks) and see how much of the block was written. The mdir's off field also points to the end of the metadata log after a commit. With some safety margin, this should be a good indicator of the minimum possible metadata_max
for a given file. Though I realize this is a rough workaround.
As a part of some larger changes I'm working on littlefs should keep track of these sort of metadata limits a bit better, so it will at least error earlier if a metadata limit is exceeded rather than fail asserts. This is a work-in-progress though.
Also from this and other feedback I think we should bring back the inline_size
config option. It seems more useful than I originally thought for controlling littlefs's behavior.
EDIT: move state needs 3 words, not 2
EDIT: EDIT: erased-state checksums (FCRCs) are not written when an mdir is full, so you don't need to account for those.
I've created a PR to add an inline_max
config, so you should be able to disable inlined files directly soon: https://github.com/littlefs-project/littlefs/pull/914
My block size is 4K. What is the minimum I can set metadata_max to? I want to disable the inline-file, which I set to 1 before, and it runs assertions.