How to decide whether such meticulous design is necessary or not? In hindsight Btrfs may have benefited, but how to decide when to and when not to in the future?

I would also be interested to know what tools are used for this. The ones I looked at seemed quite dated.. :-)

Thank you for answering! This is very interesting to learn about

Thank you for your input!

I didn't think about the hardware issues, hmm. I can't see how to do that, when the compiler guarantees get invalidated by hardware. Checks are also needed like in C? (assuming there are checks which do not get compiled out..)

Thanks fr mentioning Redox!

Agreed.

> The point being, it’s not clear yet, and to solve that requires understanding the problem, not effecting a needless rewrite in a new language.

Which is why the first question is why btrfs has issues others do not have. Some mention its CoW architecture, system design, too many features and not limiting storage to 90% and so increasing complexity. Others mention usual kernel issues.

Others mention that they had no issues to begin with and that its mixed reputation is unwarranted. I'm not clear who is right, but they are data points.

Thank you for your input in cautioning of rewrites to avoid needless work, I appreciate it.

I didn't know this requires certain features which are not available inside the kernel. I only knew all existing interfaces may be unsafe because they are in C though. Rust does not seem as useful then.

Thank you for your input.

So Rust does not decrease the complexity, but only removes certain kinds of errors which the compiler can detect. Neither logic errors nor speed regressions.

Thank you for your input.

Are they not solvable because the kernel does not give enough guarantees as it gives to userspace, because the c-interfaces of the kernel have to be wrapped in unsafe or because of other reasons (architecture, data model, kernel constraints, ...)?

Would Rust solve the non-speed issues? Rust-in-kernel discussion from August: https://lwn.net/Articles/829858/

When SwiftUI came out I learnt it by trying out each question about it. This way it was easy to get an introduction, because all were new to the technology and so were interested in figuring the questions out. And the questions were simple enough because no one had much of a grasp.

With old technology you do not necessarily have enthusiasts who try to "figure it out too" at the moment and so it gets more difficult.