lfs_bd_read return LFS_ERR_CORRUPT

[Embed-Debuger]

I'm currently using littlefs to manage my eMMC memory (4Gb), but now I'm running into a serious problem that repeats in two phases:

Step1. Each file with a size of 20M is written, for a total of 2Gb. Five threads write simultaneously.

Step2. An unexpected power failure occurs. After the file system is restarted, the file system can mount and read files, but cannot write files.

There are two other problems in step1:

1. If the file system has been used for 700 MB, power it off and restart it. The preceding problem does not occur. But littlefs initializes slowly, seemingly because the more memory is used, the slower it gets, looping through lfs_ctz_traverse thousands of times and repeating several times;

2. littlefs repeats the loop over lfs_ctz_traverse thousands of times every once in a while.

I tried versions 2.8.0 and 2.5.0 of littlefs, but nothing worked. I've looked at similar issues in lssues, but they were mostly raised before 2020, and there wasn't a clear explanation or solution.

Here are my current configuration parameters:

enum
{   
    READ_SIZE = 512,         
    PROG_SIZE = 512,          
    CACHE_SIZE = 1024*4,       
    LOOK_HEAD_SIZE = 1024*4,   
    BLOCK_SIZE = 1024*4,      
    BLOCK_COUNT = 2754560/4,      ///< 2690M
    BLOCK_CYCLE = 500, 
};

This is the call stack record:

lfs_bd_read
lfs_ctz_traverse
lfs_fs_rawtraverse
lfs_alloc
lfs_ctz_extend
lfs_file_flushedwrite
lfs_file_rawwrite
lfs_file_write

Now, I want to know:

1. lfs_bd_read What is the possible cause of LFS_ERR_CORRUPT?

2. How can you avoid this problem?

3. Can the initialization speed of littlefs be accelerated?

[ian-678]

@Embed-Debuger any progress on your issue? It sounds similar to mine in that you can mount and read the file system but cannot write and lfs_bd_read throws LFS_ERR_CORRUPT. I also have the fs mounted on a much smaller external flash chip (8MB). You were able to reproduce it by writing a large amount of data then power cycling the device?

[ian-678]

For those interested, I was also able to recreate the issue by power-cycling the device while it was writing a large file to the external flash via SPI. The corrupt state didn't occur right away so I wrote a script that power-cycled the device every 30 seconds (during the write) and left it overnight. Not sure how many resets it took to cause it.

Perhaps this is a limitation of using littlefs on external flash?

I have a workaround to format the external flash if the corrupt state occurs. I temporarily save a few key files to RAM during the format to be re-written. This seems adequate for now.

[ericmbf]

I'm having the same problem append the same file. It is failing in this conditional:

off+size > lfs->cfg->block_size

The off is equal to my block of 4096. The return LFS_ERR_CORRUPT doesn't make the LFS stop, but after sometime, I lost my main block 1, and I start to receive the following message:

../littlefs/lfs.c:1369:error: Corrupted dir pair at {0x0, 0x1}

Is there somebody else with the same problem?

[ericmbf]

Sorry guys, I just realized that my driver was deleting 64KBytes, not 4096 as I was configured.

BLOCK_SIZE = 4096

Should be 64KB. I will test now with the right block size and check I stop to have this behavior.

[YKMorsy]

For those interested, I was also able to recreate the issue by power-cycling the device while it was writing a large file to the external flash via SPI. The corrupt state didn't occur right away so I wrote a script that power-cycled the device every 30 seconds (during the write) and left it overnight. Not sure how many resets it took to cause it.

Perhaps this is a limitation of using littlefs on external flash?

I have a workaround to format the external flash if the corrupt state occurs. I temporarily save a few key files to RAM during the format to be re-written. This seems adequate for now.

This is exactly the problem I am running into. Have you found a solution? @ian-678

[ian-678]

@YKMorsy no unfortunately. I'm sticking with the workaround I mentioned above for now.