v3: Thread safety and locking support

[Tigls]

Hi,

In one of your posts, I read that v3 is already at feature parity with v2, so we decided to give it a try. We’re using it on a microcontroller with NOR flash, an RTOS, and SQLite.

After switching to v3, we started encountering frequent rbyd corruptions, and began investigating the root cause. It appears that while v3 accepts a lock configuration (similar to v2), it doesn’t actually use it internally — is that correct?

I also couldn’t find any mention of thread safety on the v3 roadmap. Is support for it planned at all?

For now, we’ll likely add our own locking around basic operations like open, write, etc., but it would be great to know your plans in this area.

Thanks!

[geky]

Oh sorry, yes, LFS_THREADSAFE is currently broken on the v3-alpha branch (along with some other API related things: trace logging, assert-error-returns, etc).

I probably could have worded things better. But to be exact, it's the v3 on-disk format that is at feature parity with v2. This is interesting from a filesystem design perspective because, in a vacuum, there is no longer a reason to choose v2 over v3 (ignoring disk compatibility, performance characteristics, support, etc). It's just a checkpoint where v3 shifts from question to goal.

The API is in someways very secondary to the disk format, so it's lower priority vs finalizing features that may impact the disk.

In the same vein, the API on the v3-alpha branch is currently unstable and susceptible to change. I would suggest sticking to a specific commit, unless you find a good reason to bump to the most recent. (In hindsight maybe the v3-alpha branch itself should be versioned? Not sure it's worth the overhead)

I also couldn’t find any mention of thread safety on the v3 roadmap. Is support for it planned at all?

Yes. LFS_THREADSAFE should be reimplemented before release. It's just low priority because there is low risk it affects the on-disk format.

This is a good time to deprecate things, but I don't think there's a reason to remove LFS_THREADSAFE.

LFS_THREADSAFE really is just lock+unlock around every function (even with the new incremental traversals), so adding these in your layer may be the best temporary solution.

What's actually missing on littlefs's side is the small function wrappers that introduce non-core features to the public API. Reimplementing those requires a bit of renaming internally to avoid name conflicts.

[geky]

I've tweaked the wording and included a link to this issue in #1111 + the most recent patch release, to hopefully help clarify expectations.