创建目录后，获取的状态是错的，报-2

[liujs6688]

在16MB的nor flash移植了littlefs2.11.2,工程和硬件之前已经移植fatfs是可以的，现在使用litllefs创建4个目录之后，每次都不能使用stat相关函数获取到正确的状态，每次都是返回-2，也不能删除，但是能使用open，read相关的函数

[BenBE]

Given your problem description (16 MiB NOR flash and LittleFS 2.11.2, open/read seems to work, but stat consistently fails), you might want to look into the exact location inside stat where the problem arises. Usually while single-stepping it often is quite obvious, when things don't align with what should happen. Also check if the functions you provide for reading/writing properly handle reading parts of sectors and some other edge cases.

Can you see if you can get a more detailed log of what LittleFS is trying to do? Also, do the provided examples, e.g. the rambd work with the settings you configured for your NOR flash?

[liujs6688]

littlefs_issue_report.md

[liujs6688]

有没有解决方案，或则其它的排查思路

[wenheng111]

Hello , was this problem finally solved? I'm facing the same issue. Is it convenient for you to share your solution? Thank you very much.

[geky]

@liujs6688, I'm going to quote your littlefs_issue_report.md here, as this is valuable info, but GitHub makes it difficult to read attached files.

Need to investigate. This does not match any known issue.

littlefs_issue_report.md:

LittleFS Issue Report: Directory Created Successfully But Immediately Not Found

Environment

• LittleFS Version: 2.11.2
• Platform: Zynq FreeRTOS
• Flash: 16MB SPI NOR Flash
• Block Size: 4096 bytes
• Program Size: 256 bytes
• Read Size: 256 bytes

Configuration

read_size = 256
prog_size = 256
block_size = 4096
block_count = 4096 (16MB / 4096)
cache_size = 4096 (equal to block_size)
lookahead_size = 512
block_cycles = 512

Problem Description

We are experiencing a critical issue where a directory is created successfully (lfs_mkdir returns 0), but immediately after creation, lfs_stat cannot find the directory (returns LFS_ERR_NOENT).

Specific Issue

1. Create root directory logs using lfs_mkdir(&lfs, "logs") → Success (returns 0)
2. Immediately check if logs exists using lfs_stat(&lfs, "logs", &info) → Fails (returns LFS_ERR_NOENT)

This happens consistently during initialization when creating multiple root directories in sequence.

Detailed Logs

Successful Directory Creation Sequence

The following shows the complete sequence for creating the logs directory:

[LFS] mkdir: path='logs'
[LFS] mkdir: actual_path='logs'
[LFS] bd_read: block=1, off=0, size=256, addr=0x00001000
[LFS] bd_read: block=0, off=0, size=256, addr=0x00000000
[LFS] bd_read: block=1, off=0, size=4096, addr=0x00001000
[LFS] mkdir: creating directory
[LFS] bd_read: block=0, off=0, size=256, addr=0x00000000
[LFS] bd_read: block=1, off=0, size=4096, addr=0x00001000
[LFS] bd_read: block=0, off=0, size=256, addr=0x00000000
[LFS] bd_read: block=1, off=0, size=256, addr=0x00001000
[LFS] bd_read: block=1, off=256, size=3840, addr=0x00001100
[LFS] bd_read: block=1, off=0, size=256, addr=0x00001000
[LFS] bd_read: block=1, off=1024, size=256, addr=0x00001400
[LFS] bd_read: block=1, off=768, size=256, addr=0x00001300
[LFS] bd_read: block=1, off=512, size=256, addr=0x00001200
... (many more bd_read operations traversing directory structure)
[LFS] bd_read: block=2060, off=256, size=256, addr=0x0080C100
[LFS] bd_erase: block=2060, addr=0x0080C000
[LFS] bd_read: block=2060, off=256, size=256, addr=0x0080C100
[LFS] bd_prog: block=2060, off=0, size=256, addr=0x0080C000
[LFS] bd_read: block=2060, off=0, size=256, addr=0x0080C000
[LFS] bd_read: block=1, off=1536, size=256, addr=0x00001600
[LFS] bd_prog: block=1, off=1280, size=256, addr=0x00001500
[LFS] bd_read: block=1, off=1280, size=1536, addr=0x00001500
[LFS] mkdir: success

Key observations:

• Many bd_read operations on blocks 0 and 1 (root directory metadata)
• New directory block allocated (block 2060)
• Block 2060 erased and programmed
• Root directory block 1 updated (prog at offset 1280)
• lfs_mkdir returns 0 (success)

Immediate Stat Check Fails

Immediately after creation, we check if the directory exists:

[LFS] stat: checking path='logs'
[LFS] stat: actual_path='logs'
[LFS] bd_read: block=1, off=0, size=256, addr=0x00001000
[LFS] bd_read: block=0, off=0, size=256, addr=0x00000000
[LFS] bd_read: block=1, off=0, size=4096, addr=0x00001000
[LFS] stat: failed, path='logs', rc=-2 (LFS_ERR_NOENT=-2, LFS_ERR_IO=-5, LFS_ERR_CORRUPT=-84)

Key observations:

• lfs_stat reads blocks 0 and 1 (root directory)
• Reads the entire block 1 (4096 bytes)
• But cannot find the logs entry
• Returns LFS_ERR_NOENT (-2)

This is the critical issue: The directory was just created, metadata was written to Flash, but lfs_stat cannot find it.

Observations

1. Directory Creation Appears Successful: The lfs_mkdir call completes without errors and performs many read/write/erase operations, suggesting the directory metadata is being written to Flash.

2. Immediate Stat Check Fails: Right after creation, lfs_stat cannot find the directory, even though it was just created.

3. Pattern: This happens for all root directories created in sequence (logs, env, fs, json). All show the same pattern: creation succeeds, but immediate stat check fails.

4. Block Operations: During creation, we see operations on:

   • Block 0 and 1 (root directory metadata)
   • Various high-numbered blocks (2060, 2062, 2064, 2066, etc.) for new directory structures
   • Multiple bd_prog operations writing metadata

5. No Sync Issues: The block device sync callback is implemented and waits for Flash status register to indicate completion.

Code Context

Directory Creation Sequence

// Create root directories
for (int i = 0; i < 4; i++) {
    res = lfs_port_mkdir(root_dirs[i]);  // logs, env, fs, json
    if (res != 0 && res != LFS_ERR_EXIST) {
        // Error handling
    }
}

// Verify logs directory exists
int is_dir = 0;
res = lfs_port_stat("logs", &is_dir, NULL);  // FAILS HERE

Block Device Operations

• read: Reads from Flash (verified working)
• prog: Programs Flash (256-byte aligned, verified working)
• erase: Erases 4096-byte blocks (verified working)
• sync: Waits for Flash status register (verified working)

Analysis

What We Know

1. Directory creation succeeds: lfs_mkdir returns 0 and performs extensive Flash operations
2. Metadata is written: We see bd_prog operations writing to block 1 (root directory) and block 2060 (new directory)
3. Immediate stat fails: Right after creation, lfs_stat cannot find the directory
4. Consistent pattern: This happens for all root directories created in sequence
5. Block device sync works: Our sync callback waits for Flash status register completion

Possible Causes

1. Cache invalidation issue: The directory entry might be in cache but not yet committed to Flash in a way that lfs_stat can see it
2. Metadata consistency: The root directory block might have been updated but the filesystem state is not yet consistent
3. Rapid sequential operations: Creating multiple directories in quick succession might cause metadata to be in an intermediate state
4. Configuration issue: Using cache_size = block_size might be causing unexpected behavior

Questions for Maintainers

1. Is explicit sync required after lfs_mkdir? Should we call lfs_fs_sync() or lfs_fs_mkconsistent() after creating directories to ensure metadata is visible?

2. Is this a known issue with rapid sequential directory creation? Has this behavior been observed before?

3. Configuration issue? Is using cache_size = block_size (4096) causing this issue? Should we use a smaller cache size?

4. Cache invalidation: Is there a cache invalidation issue where newly created directories are not immediately visible to lfs_stat?

5. Best practices: What is the recommended approach for creating multiple directories in sequence during initialization?

Additional Information

• FATFS worked correctly: The same hardware and timing worked fine with FATFS, so this is not a hardware or timing issue at the Flash level.

• Manual creation works: If we create directories manually via shell commands (with delays between operations), they work correctly. This suggests the issue might be related to rapid sequential operations.

• Power loss resilience: We switched from FATFS to LittleFS specifically for power-loss resilience, but we're seeing this issue even during normal operation (no power loss).

• Block device implementation: Our block device operations are verified working:

  • read: Reads from Flash correctly
  • prog: Programs Flash with 256-byte alignment
  • erase: Erases 4096-byte blocks correctly
  • sync: Waits for Flash status register to indicate completion

• No other tasks interfering: We've verified that no other tasks are operating on the filesystem during initialization.

RAMBD Compatibility Verification

Following your suggestion, we've verified that our NOR Flash block device implementation is compatible with the rambd example.

Verification Method

We added strict constraint checks matching rambd's implementation:

• ✅ Read operations: Check off % read_size == 0 and size % read_size == 0
• ✅ Prog operations: Check off % prog_size == 0 and size % prog_size == 0
• ✅ Boundary checks: Check off + size <= block_size

Verification Results

✅ All littlefs calls satisfy alignment requirements

From actual runtime logs, we can confirm:

• All bd_read operations: off and size are multiples of 256 (read_size)
• All bd_prog operations: off and size are multiples of 256 (prog_size)
• All operations satisfy boundary constraints
• No alignment errors occurred during the entire run

This confirms:

1. ✅ Our implementation matches rambd's specification
2. ✅ Our configuration parameters are compatible with rambd
3. ✅ littlefs correctly ensures alignment for all block device calls

Configuration Parameters

read_size = 256
prog_size = 256
block_size = 4096
block_count = 4096
cache_size = 4096 (equal to block_size)
lookahead_size = 512
block_cycles = 512

Conclusion: Our block device implementation is correct and compatible with rambd. The issue must be elsewhere, possibly in littlefs's internal metadata consistency or caching mechanism.

Request for Help

We would appreciate guidance on:

1. Whether this is expected behavior and how to work around it
2. If there's a configuration issue causing this (though rambd compatibility suggests our config is correct)
3. If there's a bug in LittleFS 2.11.2 that needs to be addressed
4. Best practices for sequential directory creation
5. Whether explicit sync is required after lfs_mkdir to ensure metadata visibility

Thank you for your time and assistance!

[geky]

• Manual creation works: If we create directories manually via shell commands (with delays between operations), they work correctly. This suggests the issue might be related to rapid sequential operations.

This is very curious. Do things work if you add sleep(1 second) calls to every bd operation?

If so, that suggests there may be a status register you need to read on the flash device to determine if the operation is complete. Or some other low-level issue that would be hard for us to debug.

Conclusion: Our block device implementation is correct and compatible with rambd. The issue must be elsewhere, possibly in littlefs's internal metadata consistency or caching mechanism.

To really prove this, you would need to reproduce the bug on a different machine. Otherwise there's too many layers that could contribute to the issue.

littlefs's test runner is a good way to test this, however documentation is unfortunately very limited at the moment. Some pointers:

• test_dirs_root is an example.
• Testing section in README.md.

If you can reproduce this in littlefs's test runner, that eliminates the possibility of any hardware/OS issue, and would make it much easier to make further progress.

---

To hopefully answer some questions:

• Is explicit sync required after lfs_mkdir? Should we call lfs_fs_sync() or lfs_fs_mkconsistent() after creating directories to ensure metadata is visible?

No, this should not be necessary. lfs_fs_mkconsistent() allows users to do work before it's necessary, but should have no observable effect on the filesystem.

• Is this a known issue with rapid sequential directory creation? Has this behavior been observed before?

I'm not aware of anything like this. Filesystems are also relatively simple w.r.t. time, really they're just massive state machines. If timing is the issue (see the above sleep suggestion), then it suggests an issue outside the filesystem.

• Configuration issue? Is using cache_size = block_size (4096) causing this issue? Should we use a smaller cache size?

This should not be an issue, but it is a suspicious corner case. Does cache_size = 2048 work? Though this could still suggest a hardware issue as cache_size = block_size maximizes pressure on the low-level prog operation.

• Cache invalidation: Is there a cache invalidation issue where newly created directories are not immediately visible to lfs_stat?

This seems unlikely. littlefs's goal is bounded RAM, as a side-effect this means very little caching. Normally this is a downside, but in this case it means littlefs should be relatively predictable.

• Best practices: What is the recommended approach for creating multiple directories in sequence during initialization?

This should not require anything special. lfs_mkdir should be able to make directories as fast as the bd read/prog/erase operations can handle.

• Various high-numbered blocks (2060, 2062, 2064, 2066, etc.) for new directory structures

This is expected. littlefs chooses a deterministic random block to allocate each mount as a part of its wear-leveling scheme, but 0 and 1 are special.

[geky]

• FATFS worked correctly: The same hardware and timing worked fine with FATFS, so this is not a hardware or timing issue at the Flash level.

Unfortunately, there are enough differences in the filesystems that this is unlikely to indicate anything useful.

Keep in mind FATFS was designed for spinny disks, and usually does very simple sector-wide bd read/writes.

[liujs6688]

我在源代码函数lfs_dir_fetchmatch添加了一个判断就可以了，能正常格式化、挂载，创建、读写目录、文件，但是删除大文件的时候会有问题

[liujs6688]

添加了一个判断就可以了，能正常格式化、挂载，创建、读写目录、文件，但是删除大文件的时候会有问题
现在测试暂时没有发现其它的问题，但是更改了源码，不知道会不会出现其它的问题