A few easy suggestions..

[JonJust]

Hi there,

I have been working on implementing LittleFS as part of a larger project I have been working on. I am newer to embedded development, so I wanted to share some of my experiences and difficulties.

I had two really big difficulties when implementing the file system. The number one issue I had was that it took me a while to realize that the user disk i/o functions were being passed block and page indexes, not addresses. I feel that this could have been a little more explicitly spelled out in lfs.h. I'm sure something like this would be more apparent to seasoned devs, but to me it was a little unintuitive.

Secondly, the file system does not verify erases in the same way that it verifies writes. Whenever you go to do a write, you will get an error response if the write ends up corrupted for whatever reason. This made it MUCH easier to pinpoint an issue with writes. Erases, however, will not give you an error response should they not go through. I had an issue with my erase function and it caused all sorts of strange issues; files over writing, "successful" writes with files disappearing, the file system corrupting, etc. I think that it would be handy to add a few lines of code verifying erases, and to return an error should an erase fail.

With that said, the system is working wonderfully, and is capable of doing what it needs to do. Thanks for all your hard work @geky !

[geky]

Hi @JonJust, thanks for posting this, this sort of feedback is always really valuable, it's easy to get sort of "in your own head" when you work on things.

The number one issue I had was that it took me a while to realize that the user disk i/o functions were being passed block and page indexes, not addresses.

Good point, this can be elaborated. I would also like to add a PORTING.md to add more info that will hopefully help writing drivers.

Secondly, the file system does not verify erases in the same way that it verifies writes.

It's not really possible without changing what erase is allowed to do. For littlefs, the state between an erase and a program is "undefined" and can be any value. This may be a bit strange since on most flash devices an erase results in all ones, but it allows littlefs to run on different storage devices where that may not be the case, such as SD cards/eMMC/EEPROM, where there is no erase (erase can be a noop), and encrypted devices, where the erase state is all ones, but encrypted (so seemingly random).

So, in a sense, not verifying erases is actually a feature.

This behavior could also be better documented in the hypothetical PORTING.md...

[pavel-kirienko]

Erases, however, will not give you an error response should they not go through.

This should be trivial to implement directly in the driver without breaking the memory abstractions geky is talking about. If your memory is erased as 0xFF's, you should be able to augment every erase operation with a subsequent read and then ensure that every byte in the erased block is 0xFF, otherwise return LFS_ERR_IO or LFS_ERR_CORRUPT.

[ZanoZ]

As a newbie , how I wish I could see this file， the great hypothetical PORTING.md...