lfs_mount: LFS_ERR_INVAL raised because of unfound superblock

[tristanclare94]

I would like to use LittleFS to log some information into an internal flash memory (stm32l4). While running the boot count example, lfs_format and lfs_mount are done successfully:

lfs_trace:3583: lfs_format -> 0
lfs_trace:3588: lfs_mount(20000304, 0800e9b0 {.context=00000000, .read=08009e9d, .prog=08009cb5, .erase=08009a9d, .sync=08009ec1, .read_size=4, .prog_size=8, .block_size=2048, .block_count=64, .block_cycles=500, .cache_size=2048, .lookahead_size=32, .read_buffer=00000000, .prog_buffer=00000000, .lookahead_buffer=00000000, .name_max=0, .file_max=0, .attr_max=0})
lfs_trace:3717: lfs_mount -> 0
lfs_trace:2480: lfs_file_open(20000304, 2000037c, "boot_count", 103)
lfs_trace:2327: lfs_file_opencfg(20000304, 2000037c, "boot_count", 103, 0800e830 {.buffer=00000000, .attrs=00000000, .attr_count=0})
lfs_trace:3737: lfs_fs_traverse(20000304, 08009ffd, 20000304)
lfs_trace:3821: lfs_fs_traverse -> 0
lfs_trace:2467: lfs_file_opencfg -> 0
lfs_trace:2484: lfs_file_open -> 0
lfs_trace:2823: lfs_file_write(20000304, 2000037c, 200017e0, 4)
lfs_trace:2948: lfs_file_write -> 4
lfs_trace:3060: lfs_file_rewind(20000304, 2000037c)
lfs_trace:2954: lfs_file_seek(20000304, 2000037c, 0, 0)
lfs_trace:2983: lfs_file_seek -> 0
lfs_trace:3067: lfs_file_rewind -> 0
lfs_trace:2489: lfs_file_close(20000304, 2000037c)
lfs_trace:2676: lfs_file_sync(20000304, 2000037c)
lfs_trace:2727: lfs_file_sync -> 0
lfs_trace:2508: lfs_file_close -> 0
lfs_trace:3727: lfs_unmount(20000304)
lfs_trace:3729: lfs_unmount -> 0

But then when the MCU resets, I am unable to mount the file system (and so the boot_count file is re-created):

lfs_trace:3588: lfs_mount(20000304, 0800e9b0 {.context=00000000, .read=08009e9d, .prog=08009cb5, .erase=08009a9d, .sync=08009ec1, .read_size=4, .prog_size=8, .block_size=2048, .block_count=64, .block_cycles=500, .cache_size=2048, .lookahead_size=32, .read_buffer=00000000, .prog_buffer=00000000, .lookahead_buffer=00000000, .name_max=0, .file_max=0, .attr_max=0})
lfs_trace:3727: lfs_unmount(20000304)
lfs_trace:3729: lfs_unmount -> 0
lfs_trace:3722: lfs_mount -> -22

-22 is LFS_ERR_INVAL (invalid parameter). Using breakpoints, I have found out that the superblock was not found and that it failed here (lfs_mount(), l.3695):

// found superblock?
    if (lfs_pair_isnull(lfs->root)) {
        err = LFS_ERR_INVAL;
        goto cleanup;
    }

The flash memory does not get erased in between. The configs seem good to me, but maybe I have missed something here. Moreover, I have tried to write and update boot count in a for loop after the first mount, and it worked fine (boot count gets updated), so I assume that writing and reading operations are not the issue here.
Did I miss something? Is there a bug?

Thanks,
Tristan

[marekr]

Ditto, same issue here. Littlefs has no issue with lfs_format and returns with a code of 0, all of it's various writes and read backs work fine in lfs_format. lfs_mount immediately after format fails due to failing to find the superblock.

[marekr]

Alright, found the flaw on my end. I was writing blocks successfully but, block 1 was overwriting block 0 due to an address masking fault on my end. This would imply that lfs_format doesn't do any kind of "full sanity check" post formatting to ensure all blocks are in place before continuing to catch these kind of faults. It appears to only verify blocks right now immediately after writing.
Such a check would be useful to have to catch both software faults and hardware faults where an address line could be broken.

[geky]

Hi, sorry about not being able to look into the original issue. It does sound like it might be something similar to what @marekr ran into.

@marekr this is quite interesting. I thought we were doing a sanity check after formatting by re-fetching the superblock (after a format the only data on disk is the superblock):
https://github.com/ARMmbed/littlefs/blob/master/lfs.c#L3648

But after changing lfs_format to write both superblocks (#193), we now write the second block after the sanity check.

It's surprising that the first fetch succeeds but that mount fails, my guess is that the uninitialized second block happens to have a lingering revision count that makes it look more recent than the superblock we just wrote.

Moving the sanity-check fetch to the last operation in lfs_format should catch this. Thanks for pointing it out!

[marekr]

@geky others are probably tripping on this too.

#441 is another issue that's most likely exactly the same problem (user error) but occluded by lfs_mount returning no error.

[mjs513]

Just as a note I had the same issue but moving the sanity check to after the force compaction function it cleared up the problem.

[geky]

Ah! I marked this as "needs fix" so I wouldn't forget about it, and then forgot about it. My bad.

Pushed up the fix here: #508, thanks for the reminder.

[mjs513]

@geky - not a problem - I am the same way - too many distractions going on. Thanks for the update.