Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Mount LittleFS loop device using standard mount command #924

Open
moefear85 opened this issue Jan 17, 2024 · 2 comments
Open

Mount LittleFS loop device using standard mount command #924

moefear85 opened this issue Jan 17, 2024 · 2 comments

Comments

@moefear85
Copy link

I created a shortcut to "lfs" as /usr/sbin/mount.lfs. Howeever, it is still only called/triggered by "mount" if I specify "-t lfs" option to mount. It would be ideal if it were possible to get mount to autodetect this. Is there anything on the littlefs side that can be done to achieve this?

Even if not, specifying "-t lfs" is not a big issue. More importantly, even then, lfs fails to mount the littleFS partition, because it assumes 512 blocksize and version 2.1, although the fs itself needs -b=4096 option and is version v2.0 (it comes from micropython images). If i call "lfs" manually, it is easy to successfully mount the loop device, because I can specify -b=4096 as an option. But it doesn't work if I use for example mount -t lfs -b=4096 ~/littlefs.bin /mnt/littlefs. Is there a way to get this working? I believe this would benefit the community, not just me.

Another problem is that the mount variant only works as sudo, although I believe that is (only) solvable by creating an fstab entry, which isn't a big deal at the moment.

@geky
Copy link
Member

geky commented Jan 17, 2024

This is really interesting. I didn't realize it was that easy to hook into mount's filesystem detection.

Is this using littlefs-fuse I'm assuming?

is version v2.0 (it comes from micropython images)

Regarding the version, by default littlefs assumes the most recent version and upgrades on first write. You can specify an explicit version with -d v2.0 to disable this if you know what version you expect.

I can see how a sort of "no-upgrade" mode would be useful. Though this would require changes in littlefs's core. Not sure exactly what it would look like.

although the fs itself needs -b=4096 option

So, littlefs does keep the magic string "littlefs" at exactly offset 8-bytes in the superblock.

But the problem is the superblock can be at either block 0 or block 1. And you can't really find block 1 without knowing the block size.

This problem is fundamental to atomically update-able superblocks. Even if we tried to keep both superblocks written, a powerloss could cause block 0 to be unreadable.

This has been explored extensively (#349, #865, #753), and at the moment I think it's unsolvable.

The best option would be:

  1. Get the physical block-size from the block device, littlefs-fuse should already be doing this:
    https://github.com/littlefs-project/littlefs-fuse/blob/2fd0c1c2414a5c91b3e0471295d5e06a64b7d666/lfs_fuse_bd.c#L36

  2. Attempt to mount every multiple of the block_size, until some threshold. But it's not clear what a good threshold would be.

Unfortunately, since the above is unbounded, I can't really recommend it as a good default.

@moefear85
Copy link
Author

nevermind.... i just realized micropython images don't contain lfs patrtitions until after flashing & first boot. thx anyways.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants