Giters

littlefs-project / littlefs

A little fail-safe filesystem designed for microcontrollers

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Mount LittleFS loop device using standard mount command

moefear85 opened this issue · comments

commented

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.

commented

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.

commented

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