Block count defined twice
tredlich00 opened this issue · comments
I don't know if this qualifies as an issue but I was uncertain how to open a discussion.
I recently ran into an issue where everything appeared to be working correctly. I was pushing multiple files into my NOR flash SPI device and littlefs was doing just fine. Then, suddenly after the sixth or seventh test I could no longer mount the media.
I received the following sequence:
lfs.c:1366:error: Corrupted dir pair at {0x0, 0x1}
Mount Error, -84
I tried formatting and got:
lfs.c:2069:debug: Bad block at 0x0
lfs.c:2074:warn: Superblock 0x0 has become unwritable
At that point my code would fail and exit into my own error handling.
As I dug deeper I found some solutions that suggested I needed to erase my NOR flash device myself and that would correct the issue. As I built my code to do this I came to realize that there is a block_count variable in lfs_t and a block_count variable in struct lfs_config. The examples that I have found all show to link the *cfg pointer in struct lfs with the instance of struct lfs_config created in memory. This seemed logical to me and I did it. That leaves me with wondering why are there two separate block_count values in two structures linked to each other? The code in lfs.c uses both of them in various locations.
Yes, I am aware that it is very easy to just set them both equal to the same value and I have already done this. I am just curious if I am using it wrong and what the reason is for what appears to me as redundant variables?
Hi @tredlich00 thanks for opening an issue. littlefs predates GitHub's discussions feature and I've been procrastinating on figuring out how that works, so that's on me (enabling discussions is irreversible).
As I built my code to do this I came to realize that there is a block_count variable in lfs_t and a block_count variable in struct lfs_config.
Ah, this is a bit of a limitation of C's "header-is-documentation". The documented struct lfs_config struct should be filled out when calling lfs_mount, but the undocumented lfs_t struct is an implementation detail that does not need to (shouldn't?) be filled out.
But lfs_t needs to be fully defined in the header file so C knows its size/alignment.
The technical reason block_count occurs twice:
You don't need to know the block count before mounting the disk. If struct lfs_config's block_count is 0, the actual block_count is read from metadata stored on disk.
We can't store this in struct lfs_config's block_count, because struct lfs_config is const, and may be stored in ROM. So the only option is a duplicated field.
Because of these duplicated fields, a ROM backed struct lfs_config is less appealing than it initially was, so in the future we may move to not requiring struct lfs_config to live as long as lfs_t. Though this may require a major version change.
As I dug deeper I found some solutions that suggested I needed to erase my NOR flash device myself and that would correct the issue.
I'm curious, what led you down this path? littlefs's lfs_format function should be stateless, unless the block device layers below littlefs has some weird external requirement.
Then, suddenly after the sixth or seventh test I could no longer mount the media.
This is all suggesting that the erase callback is not implemented correctly. Out of the factory, your device may be pre-erased, which would allow a small number of commits to be written. But then littlefs will need to erase a block for new commits, which could lead to this error. This would also explain why reformatting didn't work.