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
littlefs: Too small heap for file cache. #31524
Comments
#31597 may also be relevant. |
Disable various tests to focus on validating the file and directory counts. This is intended to confirm issue zephyrproject-rtos#31524, but it is not reproducible on nrf52840dk_nrf52840. Signed-off-by: Peter Bigot <peter.bigot@nordicsemi.no>
I am unable to reproduce this problem. Using an augmented test in https://github.com/pabigot/zephyr/commits/repro/31524 I can open the required number of files, and directories, on
@r2r0 could you please check this on your configuration? It may be specific to a particular type of flash or platform. |
Attached test fails on QEMU x86 and similar test (the same code and the same LITTLEFS config) also fails on our board with STM32WB55 (external FLASH over QSPI). |
@pabigot Thanks for quick reply. |
No, apparently I did. I'll take another look later. |
So here's what's going on. Originally the file cache used a mem_pool. With that data structure it appears metadata associated with allocations was held separately, so that the entire requested storage space was available for application use. In #28611 the I've confirmed this by verifying that the test program above passes at commit 78614bf but breaks at the immediately following commit fcd392f where the deprecated API was replaced by a heap. The Kconfig options used to allocate the space for per-file caches are completely obsoleted by the change in data structure. What I've done in #31781 is deprecate the old mem_pool Kconfig options, and add a new option that provides more direct control of the size of the memory region to allocate file caches. The chain of defaults producing that size have been updated to include the required slop so that allocating N blocks of size B works again. |
So, my guessing about problem reason was correct, nice. |
Let's leave this open until the fix is merged. |
Describe the bug
fs_open for CONFIG_FS_LITTLEFS_NUM_FILESth file returns -ENOMEM.
I.e. CONFIG_FS_LITTLEFS_NUM_FILES=3 and when fs_open is caled for 3rd file it returns -ENOMEM.
After incrementing CONFIG_FS_LITTLEFS_NUM_FILES and opening only CONFIG_FS_LITTLEFS_NUM_FILES-1 files problem is not present.
After increasing file_cache_pool (in littlefs_fs.c) even by 128 bytes problem is not present (CONFIG_FS_LITTLEFS_NUM_FILES=3).
To Reproduce
Try to open at the same time CONFIG_FS_LITTLEFS_NUM_FILES number of files on littleFS.
Expected behavior
No error from fs_open.
Impact
annoyance
Logs and console output
None
Environment (please complete the following information):
Additional context
Maybe commit fcd392f caused this problem because heap size available to user != declared size of heap.
The text was updated successfully, but these errors were encountered: