Mention use-cases and caveats in the README

[rumpeltux]

Thanks for the interesting project!
I came here looking for a filesystem that I could use in my MCU.
This project seemed to be what I was looking for. Note that I use a SDHC card for datastorage.

Only after integrating littlefs in my code and experimenting I learned that the project is not a good fit because:

• littlefs is probably not design for large files (per some bug reports, e.g. File append is not working after n cycles or 2000 bytes of data in NAND flash #188 though DESIGN.md suggests otherwise?)
• the updatable metadata blocks seem to assume that overwriting flash doesn't impose wear as long as only 1s are changed to zeros and no delete occurs. I don’t think this is true for sdcards though (after delete a sector is filled with 0), they probably do internal wear leveling? So if a block is overwritten each time anyways, keeping unchanged data seems a waste of space.

So it would be good to indicate in the README.md file what good usage patterns are and which usage patterns don't work or have performance issues.

While here, the example given in README.md also uses a very small blocksize (32 bytes) and so I’m wondering what the RAM requirement effects are when changing this (e.g. to 512bytes for standard sd cards).

[geky]

Hi @rumpeltux, thanks for the feedback. Glad you found the project interesting.

littlefs is probably not design for large files (per some bug reports, e.g. #188 though DESIGN.md suggests otherwise?)

This is true. And noted it should be mentioned in the readme.

The scalability is a problem I'm hoping to address, but it is a long journey.

the updatable metadata blocks seem to assume that overwriting flash doesn't impose wear as long as only 1s are changed to zeros and no delete occurs. I don’t think this is true for sdcards though (after delete a sector is filled with 0), they probably do internal wear leveling? So if a block is overwritten each time anyways, keeping unchanged data seems a waste of space.

You can disable littlefs's block-level wear-leveling by setting block_cycles = -1. This is a good idea on SD cards since as you mention they have their own wear-leveling scheme.

The metadata blocks also provide the atomic updates needed for power-resilience. So the duplication of metadata is still needed for littlefs to work.

While here, the example given in README.md also uses a very small blocksize (32 bytes) and so I’m wondering what the RAM requirement effects are when changing this (e.g. to 512bytes for standard sd cards).

There's no RAM requirements for larger block sizes. Not really sure why the example is using 32 bytes to be honest. The RAM requirement is only a result of the cache_size config and number of simultaneously opened files.

The tradeoff is we have to go to disk more. If you can throw RAM at the problem setting cache_size = block_size will make #188 specifically go away. Of course this is rarely an acceptable solution. : )

[e107steved]

Isn't it block_cycles = **-**1 to disable?

On a side-note, there are some really good explanations in @geky's reponses in these issues; hopefully at some point they can be brought together in some form of overarching documentation.

[geky]

@e107steved good catch, yes it's -1 to disable.