When v2 public release?

[xiaoxiang781216]

No description provided.

[geky]

Hi @xiaoxiang781216, there's no hard date. I'm hoping to get v2 out before the year is over.

The remaining tasks are:

1. Upgrade path for v1 -> v2 (over here)
2. Documentation

I know v2 has been heavily delayed, sorry about that. Some of it is me being sidetracked by unrelated things, some of it has been trying to make sure v2 is solid and future proof.

[xiaoxiang781216]

@geky, is v2-alpha-upgrade stable enough to try? for stable, I mean:
1.The layout on the flash is lock
2.The bug fix don't need to reformat the flash
3.v1 file and directory API work well
We want to try v2 version as soon as possible on our test chip, even there still has some minor defact.

Thanks
Xiang

[geky]

I don't expect v2-alpha to change except for defects. However, defects may still break the disk format. 5b26c68 is a good example (caught with a power-resilience test, but unfortunately wasn't caught until very recently).

Currently the upgrade function in v2-alpha-upgrade does not work, I need to figure out if it's just an issue with the upgrade function or an issue with the v2 changes.

I'm thinking once the v1 -> v2 upgrade is ready and working I will create an "official" v2-alpha release and give users ~2 weeks (assuming no major defects) to integrate/test the new version before releasing the v2 version and committing to the disk format.

---

The API should not change, but the disk format may still change for the next few weeks. The changes should be minor, but unfortunately any disk format changes have a big impact.

[xiaoxiang781216]

It's great, let's wait the v2-alpha release.

[husigeza]

Hello!
Any update about possible merge date ?

[geky]

Sorry about the radio silence, I've been focusing on getting everything together and haven't been doing a good job of monitoring GitHub. I owe everyone an apology for that. But it's now time to get this ball rolling.

At this point littlefs v2 is passing all of the tests I am able to throw at it and I'm happy committing to the on-disk format. I still need to put together the migration functionality and bring all of the documentation up to date (the documentation is all out of date right now), but hopefully an early "alpha" release will be useful.

I'm going to make an official "v2-alpha" release before today is over and update the PR with more info. In ~2 weeks I should be able to merge v2 as an official release (although my guesses on timing have been very terrible so far).

Thanks for the patience!

[rojer]

@geky great! we are eagerly awaiting v2. and for us, would be good if you could commit the functionality first - in our use case we are fortunate enough that don't care much about migration of existing FS structures as long as the same code can mount both new and old versions (even if read-only).

[geky]

Hi @rojer, to be clear, littlefs v2 is not disk-compatible with v1. It's unfortunate, but I'm hoping this will be the only breaking change for littlefs. This is the main reason this release has dragged on for so long.

You can read from both v2 and v1 in the same codebase, but you would effectively need a copy of both v2 and v1, which is 2x the code cost. Though I can look into creating a version of v1 without name collisions ("lfs1_mount" for example), let me know if that would be helpful.

A migration function, while invasive, would only need to be about ~1.25x the code cost as it only needs enough logic from v1 to copy over the metadata.

[rojer]

creating a version of v1 without name collisions ("lfs1_mount" for example), let me know if that would be helpful.

it definitely would. i was pretty much going to do this.

A migration function, while invasive, would only need to be about ~1.25x the code cost as it only needs enough logic from v1 to copy over the metadata.

the reason it won't be useful in our case is because of the setup we have: our (Mongoose OS) update mechanism involves two "slots": app code and FS, completely independent of each other. new code gets written into the unused app slot, new fs is created in the corresponding FS slot and then new app is booted with the new fs, mounts the old fs, copies over some files and unmounts the old fs. this has many advantages, rollback ability being the most important, but in particular it makes it possible to change filesystem types as long as new code is able to mount old fs r/o (this is the plan for eventual SPIFFS -> LFS migration as well).
to cater for LFS1 -> LFS2 transition, i will need to have code that is able to mount LFS2 in r/w and LFS1 r/o at the same time.

[geky]

Oh interesting, that is a nice system and makes upgrades almost too convenient for FS guys like me : )

I won't be able to put together v1-no-name-collision tonight (in CST), but I'll let you know when I do. If you beat me to it feel free to create a PR.

[rojer]

there's no particular rush, i have other stuff to attend to atm but i'm keeping a keen eye on the developments :)

[xiaoxiang781216]

Great!!! We will start test the v2 alpha release soon.
Thanks @geky very much.

[geky]

Ok, I created a script and branch with "lfs2" prefixes here:
https://github.com/ARMmbed/littlefs/tree/v2-alpha-prefixed

But this raises the question, how should I deliver prefixed versions? I can think of three options:

1. Don't create branches, only deliver script. Users can run the script locally if they need prefixes to compile. This is the easiest for me.
2. Make CI create a "v2-prefixed" branch every release. This is more complicated, may be error prone, and risks creating problems for users when they go to merge a new version.
3. Always use the "lfs2" prefix, for example "lfs2_remove(hi)", and don't provide a "lfs_remove(hi)". This is simple if a bit heavyhanded. The only issue I can think of is updating the version users need to rename every function call.

Thoughts?

[FreddieChopin]

I would say "1". In my opinion most of the users won't need the prefixed versions at all - they'll only use the most recent v2 and not bother about v1. Keep in mind that whatever you decide here should probably be used for v3, v4 and so on (; Even if you think there's no need for more versions, I'd say better to be prepared (; I hope you remember the issues with the very large storage (several GB on SD cards), where I think you'll have to keep the list of free nodes actually written on the disk, which quite likely won't be backwards compatible.

[FreddieChopin]

BTW there's another option for prefixes, which may turn out to be easier. Instead of providing v2 as lfs2_..., you could provide "the most recent version" (here - v2) as lfs_..., and the previous versions with different prefix (for example lfs1_... for v1). This way you'd have to add the prefixes and files only once - when changing major version. After that these files would be "frozen".

[rojer]

i think ideal for me would be to have v2 non-prefixed but also have lfs1_ somewhere in the corner, checked in and available for use for anyone who wishes. under compat/ directory, maybe - compat/lfs1.h, compat/lfs1.c

[rojer]

barring, that, next best thing is to have official lfs1-prefixed branch that has lfs v1 code with lfs1_ prefix.
point is, i need both in the namespace at once, either in one repo or in different clones of the same repo (different submodules at different commits). not a fan of having to run rename script as part of the build process.

[dpgeorge]

3. Always use the "lfs2" prefix, for example "lfs2_remove(hi)", and don't provide a "lfs_remove(hi)".

This is not such a bad idea. If v2 is a completely new on-disk format then it should be considered a completely new type of filesystem, with a new name and a new namespace for the C API. Compare with ext2, ext3, ext4. So having lfs, lfs2, lfs3, etc makes sense IMO. Having the API called lfs2_XXX makes sure that all users know they are upgrading to a new filesystem layout.

[geky]

Thanks for all of the feedback (sorry for the delay, as usual). I hate decisions like this, where there's no "right answer". I'm currently thinking I'm going to fix my indecision with more scripts.

My current thinking is add a CI job that creates prefixed branches for every version. So v1 gets a v1-prefixed branch and v2 gets a v2-prefixed branch (and any future versions get a prefixed branch). This provides any prefixes, but continues development as "lfs_" without prefix.

I do get that always using "lfs2" isn't unreasonable, but I want to push forward with just "lfs" in this repo to keep focused on moving forward. (though I do think using prefixes is a good idea in any OS repo).

(Also @FreddieChopin I do remember the issue with large storage, I've just been swamped recently :), sorry I've made you wait so long).

[rbphilip]

Hey.. I'm currently testing V1 with good success. I've pulled V2 to have a look but I've not noticed anything like a "changes since V1" document. I wonder if you could highlight the changes/improvements with V2.

[geky]

Sorry about the absence. I now have prefix branch generation working over here:

• https://github.com/geky/littlefs-test-repo
• https://github.com/geky/littlefs-test-repo/blob/master/.travis.yml#L165-L189

Let me know any feedback on the idea or if anything is concerning. I'll be bringing the script into both v1 and v2-alpha shortly.

[geky]

Hi @rbphilip, does the PR body of #85 (comment) have what you are looking for? When v2 is made I will be copying that info over into the notes on the release.

[rbphilip]

That's it. Thanks.

[geky]

I've created the release now and updated the release notes: v2.0

I'm going to close this for now but feel free to create more issues for discussions.