search

littlefs-project / littlefs

A little fail-safe filesystem designed for microcontrollers
BSD 3-Clause "New" or "Revised" License
4.91k stars 773 forks source link

On File Open how can you get starting block of File #625

Open mjs513 opened 2 years ago

mjs513 commented 2 years ago

We have been using LFS and have it successfully working on several different NOR chips and NAND chips. Now we are trying to implement MTP on a Teensy micro but ran into a problem with one particular NOR Flash (W25Q512) and seems that it just not fast enough, i.e, format+write cycles. One of the things we were thinking about was to format the blocks for the file prior to actually coping the file from the PC to the flash but to do this we need to know the starting block of the file.

Guess the question is what do I have to do to get the starting block of the file from LFS? Any help would be appreciated.

geky commented 2 years ago

Hi @mjs513, thanks for opening an issue and sorry about the late response.

The idea to format before download is quite a creative one, unfortunately I'm not sure it's one littlefs is well engineered for.

what do I have to do to get the starting block of the file from LFS?

This is unfortunately not really exposed and has a few challenges:

  1. Files are copy-on-write, aka they move when written. This means the start of the file isn't decided until writing starts. If you somehow disabled this unfortunately the filesystem would no longer be power-resilient.

  2. Files are broken into multiple blocks across disk, so you would need all of the blocks composing the file.

If you only need to update one file, you could consider using a partition table such as an MBR, effectively storing the file next to littlefs. This would sacrifice wear-leveling, but if the file is written relatively infrequently (such as firmware updates) this may be ok.

geky commented 2 years ago

Thinking about it more, it could be possible to add an additional API to allow files to be "pre-erased" in preparation for new data. But tracking this additional state would be rather complicated and involved, and likely increase the code-size for normal file writes.

It would be interesting to explore but probably low in priority on littlefs's roadmap.