throwii

New-old word: brand confusion

People who can figure this out are not the target.

How do you learn that solution curve and their tradeoffs? Swap jobs and hope you see them all in your lifetime? Read articles and hope you pick everything up correctly?

The V-model is interesting. I'm a student and kinda new to the different development models.

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

Can you tell how such evaluation on a design is done? Is some kind of formal verification, analysis or rather experimentation to figure out its properties normal?

Thank you for your input!

Do other parts stomp often? :) But true that can happen. Especially on non-ECC systems.

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..)

Sorry I was unclear :) Maybe they would limit storage to 90% now, seeing that it increases complexity. Maybe I misunderstood the prior point though.

Thanks fr mentioning Redox!

> C is generally not the problem when it comes to performance issues in the kernel, which means rewriting that thing in Rust wouldn’t magically make it faster.

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 thought the Rust compiler solves issues that you wouldn't immediately see with pure C, which is why I had the idea.

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.

Interesting decision they made, I wonder whether they would decide differently now after seeing all the complexity.

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.

Good theory, thank you.

Thank you for posting your experience!

Any rewrite must be carefully evaluated, true. And it may not be advisable. I'm trying to understand the issues.

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, ...)?