fs/littlefs: add block_size_factor mount option#19126
Open
alexcekay wants to merge 1 commit into
Open
Conversation
When a board switches storage technology but wants to mount a littlefs
filesystem onto this storage it is desired to still use the same firmware.
This almost works out of the box in NuttX with the exception of setting the
correct block size, which may be different depending on the used storage.
An incorrect block size may lead to suboptimal performance or worse.
To avoid writing a firmware variant that only differs by
CONFIG_FS_LITTLEFS_BLOCK_SIZE_FACTOR this adds the option to pass the
intended block size at the mount call. To still enable the usage of the existing
options this adds a parser for comma-separated mount options, allowing multiple
options to be passed simultaneously.
Example: "autoformat,block_size_factor=4",
"autoformat,block_size_factor=1"
This is backwards compatible: single options passed without commas continue to
work as before.
Signed-off-by: alexcekay <alexander@auterion.com>
5232dd5 to
9ae5111
Compare
|
|
||
| bool autoformat = false; | ||
| bool forceformat = false; | ||
| int block_size_factor = CONFIG_FS_LITTLEFS_BLOCK_SIZE_FACTOR; |
Contributor
There was a problem hiding this comment.
move the variable definition to the begin of function for c89
| goto errout_with_fs; | ||
| } | ||
|
|
||
| while ((tok = strsep(&tmp, ",")) != NULL) |
Contributor
There was a problem hiding this comment.
can we use strchrnul to avoid strdup?
Contributor
|
@simbit18 @raiden00pl seems like we are out of space inside our docker image: |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
When a board switches storage technology but wants to mount a littlefs filesystem onto this storage it is desired to still use the same firmware.
This almost works out of the box in NuttX with the exception of setting the correct block size, which may be different depending on the used storage. An incorrect block size may lead to suboptimal performance or worse.
To avoid writing a firmware variant that only differs by CONFIG_FS_LITTLEFS_BLOCK_SIZE_FACTOR this adds the option to pass the intended block size at the mount call. To still enable the usage of the existing options this adds a parser for comma-separated mount options, allowing multiple options to be passed simultaneously.
Example: "autoformat,block_size_factor=4",
"autoformat,block_size_factor=1"
This is backwards compatible: single options passed without commas continue to work as before.
Impact
This does not have an impact on existing users. The mount options they currently pass still work as before.
Testing
Tested on a v6s flight-controller (STM32H743VIH6) using the following test mount options:
Those were passed at the mount call:
Afterwards a breakpoint was set after the parser code and the values of the variables
autoformat,forceformatandblock_size_factorwere checked for correctness. After that it was ensured that the filesystem mounts correctly.The obvious edge-case is:
This causes a div by zero in the calculation of
fs->cfg.block_count. This however was already the case before withCONFIG_FS_LITTLEFS_BLOCK_SIZE_FACTOR, so I did not add an additional verification as this will directly be visible on the first mount try.Another edge-case is:
This semantically does not make much sense but does not cause any real problems as the two options can co-exist. In this case
forceformatis executed first. If for some reason the mounting would still fail even after that format withEFAULTthenautoformatwould format again.