problem mounting littlefs

Hi all,

I am migrating from an old(er) version of RIOT to the 7-2020 version. I run into a problem mounting the littlefs filesystem.

At initialization function lfs_dir_fetch() is invoked. On line 448 of lfs.c the block is read into memory. The mtd function that implements this returns the number of bytes read, in my case that is 256 bytes. It appears to me that the following code considers this an “errorcode” where lfs_dir_fetch() is returning by the return on line 454. In lfs_mount() the return value is checked and causes a goto to label “cleanup” where lfs_deinit() is invoked and the return value returned to the upper layer. In my application the error check fails as it only checks for negative values, but that is less important.

Is my analysis correct? How is it supposed to work?

Regards,

Bert

Hi,

Can you check if the issue is still present on the master branch?

There has been some rework on the MTD layer recently, the mtd_read_page() function used by littlefs should only return non-0 on error.

However, so should mtd_spi_nor_read() on the 2020.07 branch.

What is your setup? Are you using plain mtd_spi_nor or is there some mtd_mapper involved?

Best,

Benjamin

Thanks for your response! We are using our own mtd driver for at25f321 and qspi and that driver indeed returns the number of bytes read. I changed it to 0 in case of success and now it seems to work just fine! I have no idea why the "old" version of RIOT did not have that problem that I had.

Regards, Bert

There has been a change to the internal MTD API, now there are .read_page and .write_page functions that *must* return the number of written bytes so the MTD layer can handle the chunking.

The old .read and .write functions were changed to only return error or success as there was no way to deal with partial writes there anyway. (In hindsight we could have as well kept the old semantics there for compatibility.)

Have you considered submitting your driver for upstream inclusion?

That way it will always stay up to date with any possible API changes.

Best,

Benjamin