Extracting data with littlefs using USB

[swapnil1499]

In couple of posts and the mbed after hours video from 2018, it was mentioned that some kind of USB access was in work.. however I can't seem to find any reference to that since then ...

Has there been any update on that?

Also If not USB MSC, can MTP class be used to get littlefs data from flash?

[geky]

Wow, that feels like a long a time ago. I wonder if @c1728p9 remembers what happened to USB mass storage.

We've both moved away from core Mbed OS development and I've been focusing on problems similar to littlefs, so I'm not really up to date on the current state of things. I personally wasn't able to export USB MSC more.

If you can get the raw data for the filesystem, you should be able to run littlefs-fuse on it to access it like a kernel-level filesystem.

[oyama]

Hello, this is still at the proof of concept stage, but I have implemented a sample that deploys littlefs to the onboard flash memory of the Raspberry Pi Pico while behaving as a FAT12 file system for the host PC connected via USB. By the way, it's read-only. https://github.com/oyama/pico-littlefs-usb

A similar approach should be applicable to other microcontrollers. I'll take some time to explore potential solutions for achieving seamless writing functionality.

780 was also a related topic

[geky]

Oh, very cool!

I looked into this approach briefly at one point, writing gets tricky because you don't necessarily know what incoming data blocks belong to what file, but maybe if you write to a temporary file and rename once the dir entry is written? There's also concerns without out-of-order writes...

Still, read-only access is already quite valuable for debugging, accessing logs, etc.

Would you be opposed to adding this to a list of littlefs projects eventually?

[oyama]

Thank you.

As you pointed out, both Copy and Update from the USB host are initially sent as unnamed data blocks. Therefore, I am considering a procedure to create a temporary file using littlefs, and then writing to the corresponding file from the differences in the FAT directory information sent afterwards. It seems possible to reconstruct the out-of-order write blocks from the differences between the FAT table and the FAT directory information.

However, maintaining the directory information is the challenging part. I am thinking of storing this information in a temporary file as well. Temporary files are all over the place :-)

I would be delighted to be listed on the littlefs project list!

[geky]

It seems possible to reconstruct the out-of-order write blocks from the differences between the FAT table and the FAT directory information.

Oh smart, I've spent so long in littlefs's codebase I've started to forget other filesystems aren't always copy-on-write :)

However, maintaining the directory information is the challenging part. I am thinking of storing this information in a temporary file as well. Temporary files are all over the place :-)

Don't take look at NTFS's root directory! https://en.wikipedia.org/wiki/NTFS#Metafiles

But it's a good solution if documented well, and your documentation already looks great.

[geky]

PR here: https://github.com/littlefs-project/littlefs/pull/968. Though this should eventually move to an external wiki.

Just another thought, it may be useful to provide endpoints for both the FAT view and the raw storage in case the user has a littlefs driver on their host machine. The raw storage may not be needed most of the time but could be useful for more advanced things such as debugging the filesystem itself. Add that to the pile of ideas.