Ability to downsize a filesystem

[sosthene-nitrokey]

Hi,

In our product, we have some devices that were initialized with a block_count that was larger than the real block count.
After formatting the flash, in an update we reduced the block count, this was fine because at this point the filesystem was empty.

But recently we wanted to push an update that bumps the littlefs library version past #584 (fail mount when block count changes), which now leads to a failure to mount.

#584 mentions the idea of adding a flag in the future that would allow overriding the introduced check.

Would it be possible to introduce this flag?

What would be the risk to just ignore this check for filesystems that were shrunk ? Is there any risk that the block_count in the superblock is used somewhere else?

Is it possible to make it so that the flag will overwrite the block_count the next time the superblock is relocated.

Maybe it would make sense when that happens to add a check that none of the now-deleted blocks are in use.

[geky]

Hi @sosthene-nitrokey! Sorry about the late response. Thanks for creating the issues/PRs.

It should be noted this is very high risk. littlefs initializes its allocator to a random position in storage to help with wear-leveling, so the last block could be in-use even if the filesystem is relatively small. But I guess if it's working it's working.

If the filesystem is truly empty (or close to empty), maybe a better strategy would be to:

1. Mount with the old block_count
2. Get the actual block_count with lfs_fs_stat
3. Reformat if block_count == old block_count

If that doesn't work, my preference would be #1094 (I have some comments but may need to wait until tomorrow). I don't think we should encourage incorrect on-disk configurations.

Though I have been considering adding LFS_M_FORCE (for a read-only filesystem) and LFS_M_FORCEWITHRECKLESSABANDON (for a read-write filesystem), but on a branch that introduces other mount flags. I don't think we can make it block_count specific though as this branch has ran into issues exhausting all 32 flags in a uint32_t.

The timing is unfortunate as I want to settle littlefs into a sort of soft "feature-freeze" for a bit, but I suppose we can have one more minor release.

---

What would be the risk to just ignore this check for filesystems that were shrunk ? Is there any risk that the block_count in the superblock is used somewhere else?

I don't think there's anything tricky with block_count, the only issue is if those blocks are in use.

Is it possible to make it so that the flag will overwrite the block_count the next time the superblock is relocated.

Hmm, in theory it's possible, but I'm not sure it's worth it vs eagerly updating the block_count (like in #1094). Commits are relatively cheap, and in theory you update the block_count ~1 time in a filesystem's lifetime.

Maybe it would make sense when that happens to add a check that none of the now-deleted blocks are in use.

Ah! I see now this was written before the work you did in #1094 :)

[sosthene-nitrokey]

If the filesystem is truly empty (or close to empty), maybe a better strategy would be to:

1. Mount with the old block_count

2. Get the actual block_count with [`lfs_fs_stat`](https://github.com/littlefs-project/littlefs/blob/8ed63b27be79ab59ee1cd15a950ddd64e7a602f7/lfs.h#L712-L716)

3. Reformat if block_count == old block_count

In our case it was empty when we started mounting it with the reduced block count, but now it should contain some data that can't be lost.

Though I have been considering adding LFS_M_FORCE (for a read-only filesystem) and LFS_M_FORCEWITHRECKLESSABANDON (for a read-write filesystem), but on a branch that introduces other mount flags. I don't think we can make it block_count specific though as this branch has ran into issues exhausting all 32 flags in a uint32_t.

That's a lot of flags? I'm curious what those are, given that AFAIK there are none on mount today, and that #1096 adds mount flags.

The timing is unfortunate as I want to settle littlefs into a sort of soft "feature-freeze" for a bit, but I suppose we can have one more minor release.

Don't feel pressured to have a release for this feature. We're going to have to backport it to 2.9 for our case since anyway the 2.10 path changes will require us to check and test extensively that it doesn't break anything, and we don't want to do that at the same time as other littlefs changes to ease debugging.

[geky]

In our case it was empty when we started mounting it with the reduced block count, but now it should contain some data that can't be lost.

Ah I see. I'm guessing this won't be a problem for filesystems created after the block_count checks were introduced.

Unfortunately, as mentioned in the PR, this API will probably be mostly useless for other users given littlefs's pseudorandom block allocation.

That's a lot of flags? I'm curious what those are, given that AFAIK there are none on mount today, and that #1096 adds mount flags.

Yes... Some of the problem is I'm trying to predict the future, which isn't the smartest thing to do... But I figure it's better than trying to deprecate flags if we end up with too many...

Currently planned flags, though I'm not sure these will all make it in:

m_flags:                                                                   
                                                                           
LFS_M_RDWR              0x00000000  ---- ---- ---- ---- ---- ---- ---- ----
LFS_M_RDONLY            0x00000001  ---- ---- ---- ---- ---- ---- ---- ---1
LFS_M_STRICT            0x00000002  ---- ---- ---- ---- ---- ---- ---- --1-
LFS_M_FORCE             0x00000004  ---- ---- ---- ---- ---- ---- ---- -1--
LFS_M_FORCEWITHRECKLESSABANDON                                             
                        0x00000008  ---- ---- ---- ---- ---- ---- ---- 1---
                                                                           
LFS_M_FLUSH             0x00000040  ---- ---- ---- ---- ---- ---- -1-- ----
LFS_M_SYNC              0x00000080  ---- ---- ---- ---- ---- ---- 1--- ----
LFS_M_DEDUP?            0x00000200  ---- ---- ---- ---- ---- --1- ---- ----
LFS_M_COMPR?            0x00000400  ---- ---- ---- ---- ---- -1-- ---- ----
                                                                           
LFS_M_REVDBG            0x00000010  ---- ---- ---- ---- ---- ---- ---1 ----
LFS_M_REVNOISE          0x00000020  ---- ---- ---- ---- ---- ---- --1- ----
LFS_M_CKPROGS           0x00000800  ---- ---- ---- ---- ---- 1--- ---- ----
LFS_M_CKFETCHES         0x00001000  ---- ---- ---- ---- ---1 ---- ---- ----
LFS_M_CKMETAPARITY      0x00002000  ---- ---- ---- ---- --1- ---- ---- ----
LFS_M_CKMETAREDUNDREADS 0x00004000  ---- ---- ---- ---- -1-- ---- ---- ----
LFS_M_CKDATACKSUMREADS  0x00008000  ---- ---- ---- ---- 1--- ---- ---- ----
                                                                           
LFS_M_MKCONSISTENT      0x00010000  ---- ---- ---- ---1 ---- ---- ---- ----
LFS_M_LOOKAHEAD         0x00020000  ---- ---- ---- --1- ---- ---- ---- ----
LFS_M_PREERASE          0x00040000  ---- ---- ---- -1-- ---- ---- ---- ----
LFS_M_COMPACT           0x00080000  ---- ---- ---- 1--- ---- ---- ---- ----
LFS_M_CKMETA            0x00100000  ---- ---- ---1 ---- ---- ---- ---- ----
LFS_M_CKDATA            0x00200000  ---- ---- --1- ---- ---- ---- ---- ----
LFS_M_REPAIRMETA        0x00400000  ---- ---- -1-- ---- ---- ---- ---- ----
LFS_M_REPAIRDATA        0x00800000  ---- ---- 1--- ---- ---- ---- ---- ----
                                                                           
LFS_m_BMAPCACHE         0x01000000  ---- ---1 ---- ---- ---- ---- ---- ----
LFS_m_BMAPSLOW          0x02000000  ---- --1- ---- ---- ---- ---- ---- ----
LFS_m_BMAPFAST          0x03000000  ---- --11 ---- ---- ---- ---- ---- ----
LFS_m_DEDAG             0x04000000  ---- -1-- ---- ---- ---- ---- ---- ----
LFS_m_DEDUP             0x08000000  ---- 1--- ---- ---- ---- ---- ---- ----
                                                                           
LFS_m_METAR1            0x01000000  ---1 ---- ---- ---- ---- ---- ---- ----
LFS_m_METAR2            0x02000000  --1- ---- ---- ---- ---- ---- ---- ----
LFS_m_METAR3            0x03000000  --11 ---- ---- ---- ---- ---- ---- ----
LFS_m_DATAR1            0x10000000  -1-- ---- ---- ---- ---- ---- ---- ----
LFS_m_DATAR2            0x20000000  1--- ---- ---- ---- ---- ---- ---- ----
LFS_m_DATAR3            0x30000000  11-- ---- ---- ---- ---- ---- ---- ----
                                    '---.---' '---.---' '-.--''-.--''--.--'
                                        f         t       ck    o      m   

• LFS_M_RDWR - Mount the filesystem as read and write

• LFS_M_RDONLY - Mount the filesystem as read only

• LFS_M_STRICT - Error if on-disk config is different

• LFS_M_FORCE - Allow mounting an incompat filesystem read only

• LFS_M_FORCEWITHRECKLESSABANDON - Allow mounting an incompat filesystem read and write

• LFS_M_FLUSH - Open all files with LFS_O_FLUSH

• LFS_M_SYNC - Open all files with LFS_O_SYNC

• LFS_M_DEDUP? - Open all files with LFS_O_DEDUP

• LFS_M_COMPR? - Open all files with LFS_O_COMPR

• LFS_M_REVDBG - Add debug info to revision counts

• LFS_M_REVNOISE - Add noise to revision counts

• LFS_M_CKPROGS - Check progs by reading back progged data

• LFS_M_CKFETCHES - Check block checksums before first use

• LFS_M_CKMETAPARITY - Check metadata tag parity bits

• LFS_M_CKMETAREDUNDREADS - Check metadata redund blocks on reads

• LFS_M_CKDATACKSUMREADS - Check data checksums on reads

• LFS_M_MKCONSISTENT - Make the filesystem consistent

• LFS_M_LOOKAHEAD - Populate the lookahead buffer

• LFS_M_PREERASE - Preerase unused blocks

• LFS_M_COMPACT - Compat metadata logs

• LFS_M_CKMETA - Check metadata checksums

• LFS_M_CKDATA - Check data checksums

• LFS_M_REPAIRMETA - Repair metadata blocks

• LFS_M_REPAIRDATA - Repair data blocks

• LFS_m_BMAPCACHE - Use the block-map as a cache

• LFS_m_BMAPSLOW - Use the block-map slow allocation algorithm

• LFS_m_BMAPFAST - Use the block-map fast allocation algorithm

• LFS_m_DEDAG - Use the dedup tree for shared references

• LFS_m_DEDUP - Use the dedup tree to dedup blocks

• LFS_m_METAR1 - Mount with level-1 metadata redund

• LFS_m_METAR2 - Mount with level-2 metadata redund

• LFS_m_METAR3 - Mount with level-3 metadata redund

• LFS_m_DATAR1 - Mount with level-1 data redund

• LFS_m_DATAR2 - Mount with level-2 data redund

• LFS_m_DATAR3 - Mount with level-3 data redund

A lot of these come from planned error detection/correction features.

A number are also convenience flags, LFS_M_MKCONSISTENT vs calling lfs_fs_mkconsistent after mount, which I could see the argument against. But reserving them here does allow for a more convenient API for users on systems where convenience > strict code cost.

[geky]

Don't feel pressured to have a release for this feature. We're going to have to backport it to 2.9 for our case since anyway the 2.10 path changes will require us to check and test extensively that it doesn't break anything, and we don't want to do that at the same time as other littlefs changes to ease debugging.

It's just worth noting this feature freeze may last several months.

Consider also waiting a week or two before planning potentially-breaking API changes...

I am curious if you find actual cases of breakage from the path changes. It's of course a risk, but most of the behavior that was changed was fairly nonsensical.

[geky]

Just checking, but I assume with #1094 going in, #1096 is no longer necessary?

The only case not covered by #1094 is if you want to mount a filesystem readonly. But with the current API, mounting with the old (larger) block_count is safe as long as you don't perform any write operations. (Or if you want to assert no writes, you can always add your own asserts to the bd prog/erase operations).

[sosthene-nitrokey]

It's not "necessary" but I think it's still desirable (for example to grow the filesystem too).

In our case we go through our Rust bindings that define the block-count at compile time through generics, which makes it painful to mount it twice with two different block counts, so we're going to use #1096 on our branch with #1094 backported to 2.9.

We have a refactor on the way to remove those generics and make it dynamic. So by the time we upgrade to 2.10 and back to upstream we're going to have this ready and will be able to change the block count dynamically and skip #1096.

[geky]

Ah, I see.

Hmm, could you add a standalone function that mounts, updates block_count with lfs_fs_grow, and then unmounts, before the Filesystem::mount takes over? Maybe with a stack-allocated struct lfs_config? That would avoid needing an API change.

Though as a temporarily solution, local changes to ignore the on-disk block_count doesn't seem unreasonable.

---

This is a bit of a long-term plan, so maybe unhelpful, but I want to do something similar with lfs.c and move away from the static struct lfs_config to only needed struct lfs_config allocated for the lfs_mount call. The potential savings of making struct lfs_config static const hasn't seemed worth the duplicate definitions we end up with for variable config (block_count, file_max, etc).

Eventually, the config system needs a rework, hopefully with ifdefs for all of the struct lfs_config members for true compile-time config.

Though how that would map to Rust I'm not sure... I know Rust has compile-time feature flags, but I'm not sure how you specify compile-time config... build.rs + environment variables at build time?

[sosthene-nitrokey]

Rust has "feature flags" for crates and in "build.rs" we can use -D for the compiler flags, so #ifdefs can be adapted to rust bindings without issue. We already use that to expose LFS_NO_INTRINSIC, LFS_NO_ASSERT, LFS_YES_TRACE, LFS_NO_MALLOC and LFS_MULTIVERSION.

More flags is just a couple more lines for each in the bindings.

I think the only things that are really hard to make bindings for would be macros in the public APIs and variadic functions, but even then don't worry too much about it Rust has very good C compatibility and issues can be worked around.

Hmm, could you add a standalone function that mounts, updates block_count with lfs_fs_grow, and then unmounts, before the Filesystem::mount takes over? Maybe with a stack-allocated struct lfs_config? That would avoid needing an API change.

Yes that would also be a possibility. We're going to go with the solution that requires the least changes in our firmware logic for now.