-
Notifications
You must be signed in to change notification settings - Fork 793
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Extending the partition #238
Comments
Huh, that's an interesting problem. I don't think there's an easy solution at the moment. One option, if you're willing to modify littlefs, is to extend the I had to do something similar for the v1->v2 migration, that may make a good starting point: |
Thanks, I looked into it, but I'd rather leave the LFS code untouched. There could be a little class between LFS and the flash driver during this firmware upgrade, which returns error if the FS tries to access the protected area. The question is, will this area be usable after the migration, or does LittleFS store that those blocks are bad? There's another thing that came to my mind. Correct me if I'm wrong, but I think that the LFS code might not care about the block count written in the superblock. It uses |
Oh! That is a better way to solve this. Currently littlefs does not track bad blocks, it will circle around and try to use those blocks again.
I should also mention that this isn't true. littlefs allocates from a random offset into flash that is generated every mount. Because of how its seeded it may always start at 0 after format, but I'm not sure you can rely on that.
Oh, that's true. But it sounds like a bug. At the very least it should print a warning if these don't match. My gut says littlefs should pick up and use the superblock's value if it's <= cfg.block_count, but this would have a performance and code size impact... My 2 cents is that having the block device report the reserved blocks as "bad" (LFS_ERR_CORRUPT) is the best way to solve this. Maybe we should add an additional error code to tell the filesystem the block is just unavailable (LFS_ERR_PERM?). That would make this an intentional feature and keep it from breaking if littlefs tracks bad blocks in the future. |
Oh, I totally missed that. Thanks!
Good idea. I thought about returning |
Well, one problem is that littlefs is cautious about error codes it doesn't recognize. Besides LFS_ERR_CORRUPT, any other error codes will cause littlefs to halt. Currently littlefs only takes corrective action on LFS_ERR_CORRUPT. I think some sort of "block in use" error code would be quite useful (maybe actually LFS_ERR_BUSY?). It would at least let me clean up the migration code a bit. |
Hi!
We are currently trying to figure out a way to change our FS-less data storage to LittleFS.
The idea is:
It's sort of easy to do, except the last step. The problem is that the number of blocks are written in the superblock at format, and I haven't found a way to expand the partition without reformatting. I have checked the code, and I couldn't find if the block number in the superblock is used at all.
So I guess we could:
All of these are pretty hacky, so I'm curious if anyone has other ideas on how to do it.
Thank you in advance.
The text was updated successfully, but these errors were encountered: