Memory allocation for littlefs and running out of space

[Mike Austin (LPI)]

Hardware: nRF52832 on the nRF52-DK

SDK: nRF Connect v2.0.0

IDE: Visual Studio Code 1.73.1 with nRF Connect for VS Code (v2022.11.140) extension

I'm trying to get familiar with writing and reading information from the littlefs on my nRF52832.  The end goal is to have a log file that I will write prior to going into SYSTEM_OFF, and this will then get read back when the device exists SYSTEM_OFF, updated with new information, and then re-written to the littlefs.

I've been using the littlefs example (.../samples/subsys/fs/littlefs/) as a basis.  All I've changed is to add some MCUBoot functionality and to add fixed partitions for my littlefs_storage space in Flash, as in my end code, I'll be using the settings_storage for settings and NVS, and want to control the amount of memory I allocate for littlefs.  If I set up the littlefs parition as follows, my example (attached below) works as expected.

littlefs_storage:
  address: 0x7a000
  size: 0x6000
  placement:
    before: 
    - end
  region: flash_primary

However in my end code, I won't have this much space available, and so I have been experimenting with reducing the fixed partition space for littlefs, with mixed results.  If I set my fixed partition as follows:

littlefs_storage:
  address: 0x7e000
  size: 0x2000
  placement:
    before: 
    - end
  region: flash_primary

and then if I have TEST_FILE_SIZE = 64, everything works.  But if I set TEST_FILE_SIZE = 65 or higher, then I get the following errors:

*** Booting Zephyr OS build v3.0.99-ncs1  ***
I: Starting bootloader
I: Primary image: magic=unset, swap_type=0x1, copy_done=0x3, image_ok=0x3
I: Secondary image: magic=unset, swap_type=0x1, copy_done=0x3, image_ok=0x3
I: Boot source: none
I: Swap type: none
I: Bootloader chainload address offset: 0xc000
�*** Booting Zephyr OS build v3.0.99-ncs1  ***
Sample program to r/w files on littlefs
Area 6 at 0x7e000 on NRF_FLASH_DRV_NAME for 8192 bytes
I: LittleFS version 2.4, disk version 2.0
I: FS at NRF_FLASH_DRV_NAME:0x7e000 is 2 0x1000-byte blocks with 512 cycle
I: sizes: rd 16 ; pr 16 ; ca 64 ; la 32
I: /lfs mounted
/lfs mount: 0
/lfs: bsize = 16 ; frsize = 4096 ; blocks = 2 ; bfree = 0

Listing dir /lfs ...
[FILE] boot_count (size = 1)
[FILE] pattern.bin (size = 0)
/lfs/boot_count read count:2 (bytes: 1)
/lfs/boot_count write new boot count 3: [wr:1]
I: Test file: /lfs/pattern.bin not found, create one!
------ FILE: /lfs/pattern.bin ------
01 55 55 55 55 55 55 55 02 55 55 55 55 55 55 55
03 55 55 55 55 55 55 55 04 55 55 55 55 55 55 55
05 55 55 55 55 55 55 55 06 55 55 55 55 55 55 55
07 55 55 55 55 55 55 55 08 55 55 55 55 55 55 55
aa 
E: WEST_TOPDIR/modules/fs/littlefs/lfs.c:567: No more free space 3
E: file write error (-28)
file write error (-28)
E: FAIL: write /lfs/pattern.bin: -28
I: /lfs unmounted
/lfs unmount: 0

This appears to be indicating that I am running out of space, but given I've allocated 8kB of flash, and I'm only trying to store 65 bytes in total (/boot count and /pattern.bin), I can't understand why this is occuring.

Can anyone with some experience in littlefs give me some pointers as to how I can resolve this?  Or at least help me understand why I'm getting the "No more free space" error with 8kB of flash and only 65 bytes of info being written to it?

Here is my example code:

1104.littlefs_example.zip

Thanks,

Mike

[dejans]

Hi,

What is minimum partition size of the littlefs_storage_partition that you got working with TEST_FILE_SIZE=64?

Best regards,
Dejan

[Mike Austin (LPI)]

Hi Dejan,

It appears to work with 0x2000. If I attempt to allocate less than this amount of memory for the littlefs_storage, I get an error on first boot up saying I don't have enough space.  So, it appears even if I don't want to store anything in littlefs, I need at least 8kB of flash as an overhead.

Then, as I increase the amount of data I want to store, I need to increase the amount of flash I allocate, but I always need the same amount of space free as I am currently consuming to store my data if I want to be able to read in the information in from the file and then write back to it.

For example, if I wanted to store 4kB of data, I need:

• 8kB of memory for the overhead
• 4kB of memory to store the data
• 4kB of additional memory, presumably to allow the new data to be written to flash without impacting on the old data (I think this is part of the littlefs power failure tolerance design)

So, this means 4kB of littlefs storage needs 16kB of flash!!

Similarly, if I wanted to store 8kB of data, I would need:

• 8kB of memory for the overhead
• 8kB of memory to store the data
• 8kB of additional memory.

Which is basically using up all the available flash memory I have in my nRF52832 chip :-(

In my end application, I need to allow 8kB of flash for settings and NVS storage (I'm trying to combine the two in the same flash partition), which means I'll have, at most, 16kB for littlefs.  Based on the above, this means I can only store 4kB of data in this partition.

I've worked out that, once I've read the file contents into RAM, I can fs_unlilnk() the file in littlefs and hence free up the "additional memory" described above.  I can then write the updated file contents from RAM to flash, meaning I can now fit 8kB of data into 8kB of allocated littlefs_storage (before I could only fit 4kB).

But I still want to understand what is consuming the 8kB of flash overhead, and if there is anyway I can reduce or eliminate this?

Regards,

Mike

[dejans]

Hi Mike,

I have managed to reproduce your issue. However, there is a difference that not only lower, but also higher partition sizes from pm_static.yml produced build errors. Build fails due to partitioning problem with the error "Failed to partition region flash_primary".

Best regards,
Dejan

[dejans]

Hi Mike,

The reserved space of 2 flash pages (sectors) is needed for the filesystem and this space cannot be reduced. 
If you want to use file system only for logging, you could consider using Flash Circular Buffer (FCB) instead of file system.

Best regards,
Dejan

[Mike Austin (LPI)]

Hi Dejan,

Thanks for the reply. I had been reading up on the littlefs implementation on GitHub here: 

https://github.com/ARMmbed/littlefs/issues/95

That is a few years old now, and seems to indicate that the superblock requirement has been removed, but that littlefs needs at least 3 blocks if I’m trying to store just one file. This aligns with what I’m seeing. And if I want to keep the power-loss resilience feature of littlefs, then I need at least 4 blocks, assuming my file is smaller than 1 block in total.

I’m wanting to have a file of up to 8kB, which means I’d need:

2 x blocks for directories = 8kB

2 x blocks for file storage = 8kB

2 x blocks for COW = 8kB

This is then consuming my entire internal flash allocation. So, seems littlefs is not great unless you have external flash, which is what I’ll probably need to look into.

Do you know if it’s possible to reduce the block size to < flash page size? I’m only saving the one file in the root directory, so needing 2 full pages of flash isn’t very efficient.

This discussion seems to indicate that it’s possible to reduce block size:

https://github.com/littlefs-project/littlefs/issues/738

I’m needing to use littlefs in my application as I need to access the logged data over BLE from my App

Cheers,

Mike

[dejans]

Hi Mike,

It is not possible to reduce the block size to a value smaller than the flash page size.

Best regards,
Dejan

[Mike Austin (LPI)]

Thanks Dejan.

You can close this one off now

Regards,

Mike