LittleFS fails when block count is greater than block size

[richesonk]

Describe the bug
When LittleFS is configured with block count greater than block_size, the filesystem will fail after some amount of time writing data to the file system. The error reported is "Corrupted dir pair"

To Reproduce

1. Use a flash part with LittleFS that requires configuring block count > block size
2. Set up repeated writes to the filesystem

Expected behavior
System should work without issue until the flash is worn out from the repeated writes

Impact
This is currently a show stopper for me. The project I am working on is a long term data logger so not being able to run for more than a few minutes is a major impact to our progress.

Logs and console output
I don't have the console output in front of me but can recreate and provide if needed

Environment (please complete the following information):

• OS: Windows
• Zephyr via Nordic NRF Connect
• v2.6.0-rc1-ncs1

Additional context
This issue has already been resolved in the upstream littlefs repo (see the first bullet here littlefs-project/littlefs#487). Syncing to the latest release of littlefs will address this issue.

[richesonk]

Unfortunately, i think I have discovered that I was wrong in asserting that updating to the latest LittleFS version will fix the issue I am seeing. I still think this is a good idea, but I have done a little testing with what I believe are properly updated lfs.c and lfs.h files to match v2.4.1 and I am still seeing the issue.

[richesonk]

I have managed to reproduce the issue with a minimally modified version of the littlefs sample. Using the attached main.c (modified from zephyr/samples/subsys/fs/littlefs/src/main.c) running on a board configured with a Macronix MX25U2G45 QSPI NOR part as shown below (forgive the MX25R64 comments and naming, this was derived from the nRF52840 DK part, the JEDEC ID and SFDP are updated to match the MX25U2G45 datasheet).

As shown below (partition size 16MB), the sample will work for greater than 20 min (presumably if left to run to completion, it will complete successfully when the device gets full). However, when I set the size of the storage partition to anything greater than 16MB (say 32MB) the sample begins to fail after 5-15 minutes reporting a failure to write (-14). I am also always setting the CONFIG_APP_WIPE_STORAGE=y option to force LFS to format the partition ensuring consistency between the configuration and what is on the flash part itself.

&qspi {
	status = "okay";
	sck-pin = <19>;
	io-pins = <20>, <21>, <22>, <23>;
	csn-pins = <17>;
	mx25r64: mx25r6435f@0 {
		compatible = "nordic,qspi-nor";
		reg = <0>;
		/* MX24R64 supports only pp and pp4io */
		writeoc = "pp4io";
		/* MX24R64 supports all readoc options */
		readoc = "read4io";
		sck-frequency = <8000000>;
		label = "MX25R64";
		jedec-id = [c2 25 3C];
		sfdp-bfp = [
			e5 20 fb ff  ff ff ff 7f  44 eb 08 6b  08 3b 04 bb
			fe ff ff ff  ff ff 00 ff  ff ff 44 eb  0c 20 0f 52
			10 d8 00 ff  87 49 b5 00  84 d2 04 e2  44 03 67 38
			30 b0 30 b0  f7 bd d5 5c  4a 9e 29 ff  f0 50 f9 85
		];
		size = <2147483648>;
		has-dpd;
		t-enter-dpd = <10000>;
		t-exit-dpd = <35000>;

	  partitions {
	  	compatible = "fixed-partitions";
	  	#address-cells = <1>;
	  	#size-cells = <1>;

			/*
			 * Storage partition will be used by FCB/LittleFS/NVS
			 * if enabled.
			 */
	  	partition@0 {
	  		label = "storage";
	  		reg = <0x00000000 0x01000000>;
	  	};
	  };
	};
};

main.zip

[richesonk]

I have added some debug statements to determine where/when the failure is occurring. Updated file is attached. Unfortunately, failure time is not on the order of 45 minutes, but (at least after 2 runs) seems to fail consistently after 32712 iterations.
main.zip

[richesonk]

Additional information. Results above (45 minute failure time after 32712 iterations) was with the storage partition configured for 24MB. Re-configuring for 32MB storage partition, results in a ~15 minute failure time on iteration 9230. Setting a breakpoint and stepping into the code shows the result is coming from the following call chain:

fs_write() ->
  littlefs_write() ->
    lfs_file_write() ->
      lfs_file_rawwrite() ->
        lfs_ctz_extend() ->
          lfs_alloc() ->
            lfs_fs_rawtraverse() ->
              It's unclear to me exactly where the error gets generated from here, but lfs_rawtraverse() certainly returns an error

(reminder, I am using the v2.4.1 version of the lfs.c file copied/merged in to my zephyr code base)

[richesonk]

A little further debugging today has allowed me to get to the line that is returning the error. Here is the call tree from above with the additional information:

fs_write() ->
  littlefs_write() ->
    lfs_file_write() ->
      lfs_file_rawwrite() ->
        lfs_ctz_extend() ->
          lfs_alloc() ->
            lfs_fs_rawtraverse() ->
              lfs_ctz_traverse() ->
                lfs_bd_read() -> The error happens on the loop iteration where index = 2 and count = 2
                  On entry to this function, the comparison of block > lfs->cfg->block_count fails,
                  causing the function to return LFS_ERR_CORRUPT

[cfriedt]

Setting to low as it is really tracking an external bug.