esp_littlefs_info() returns used_bytes > total_bytes

[hmimberg]

Hi,
when using this library on an ESP Wrover, we encountered the behaviour, that the function esp_littlefs_info() returns a bigger number for used_byte than for total_bytes.

esp_vfs_littlefs_conf_t conf = {
    .base_path = "/littlefs",
    .partition_label = "littlefs",
    .format_if_mount_failed = true,
    .dont_mount = false,
};
 size_t total = 0, used = 0;
 esp_littlefs_info(conf.partition_label, &total, &used);

 printf("get_free_spiffs_size: total: %zu, used: %zu, free: %zu\n", total, used, total-used);

returns:
get_free_spiffs_size: total: 5238784, used: 5267456, free: 4294938624

Our usecase is opening a file and periodically (with 1Hz) appending about 250 Bytes.
Before every write we check partition size like above.
Is there perhabs some min space that should be kept free on the partition?
We cancel recording when free space is less than 20000 Bytes. Yet, this error still occurs.

Thanks in advance
Kind regards.

[BrianPugh]

Thats an interesting error I haven't seen before; however, looking at the upstream lfs documentation, it has this to say about lfs_fs_size:

// Note: Result is best effort. If files share COW structures, the returned
// size may be larger than the filesystem actually is.

So there doesn't seem to be an easy way to get an exact amount of used bytes in the system. A mediocre solution is to use an int instead of size_t so you can easily detect when the remaining space "goes negative" and halt.

semi-related; I should do something similar as this PR in the arduino fork of this project.
lorol/LITTLEFS#45

[hmimberg]

Thank you for the fast response.
Catching the case is not a problem. We are doing that already.

[BrianPugh]

cool, as for now, I don't think there's really anything I can do as it's an upstream problem/design-limitation.

A mitigation is I could return the min(lfs_used, lfs_filesystem_size) so this doesn't catch people off guard.

[BrianPugh]

@hmimberg so I wasn't able to reproduce this bug, but i added in some mitigation:

#72

If this doesn't fix your issue (or you can find a way to have the test reproduce the issue), i'll reopen this. Thanks!