Hacker News Reader

Comment by magicalhippo | Hacker News Reader

That you or the user dislike some of the downsides does not invalidate an option.

I will absolutely agree with you that merging that repair code would be vastly preferable to you and the users. And again, if bcachefs was mature and stable, I absolutely think users should get a way to repair ASAP.

But bcachefs is currently experimental and thus one can reasonably expect users to be prepared to deal with the consequences of that. And hence the kernel team, with Linus at the top, should be able to assume this when making decisions.

If you have users who are not prepared for this, you have a different problem and should seek how to fix that ASAP. Best would probably be to figure out how to dissuade them from installing. In any case, not doing something to prevent that scenario would be a disservice to those users.

View on HN

bcachefs has had active users, with real data that they want to protect, since before it was merged.

A lot of the bcachefs users are using it explicitly because they've been burned by btrfs and need something more reliable.

I am being much, much more conservative with removing the experimental label than past practice, but I have been very explicit that while it may not be perfect yet and users should expect some hiccups, I support it like any other stable production filesystem.

That's been key to getting it stabilized: setting a high expectations. Users know that if they find a critical bug it's going to be top priority.

Given the bug fixes and changes, the experimental flag seems quite appropriate to me. That's not a bad thing.

However, it was put in the kernel as experimental. That carries with it implications.

As such, while it's very commendable that you wish to support the experimental bcachefs as-if it was production ready, you cannot reasonably impose that wish upon the rest of the kernel.

That said I think you and your small team is doing a commendable job, and I strongly wish you succeed in making bcachefs feature complete and production ready. And I say that as someone who really, really likes ZFS and run it on my Linux boxes.

All I need to support bcachefs is for the same rules to apply as they are to every other subsystem.

From what I have read and recall, the same rules do apply.

Rather, the disagreement seems to be over what constitutes a feature and what constitutes a bugfix.

As I recall, your view is that the repair code is part of the bugfix. However Linus deems it a feature, and thus applied the "no new features outside the merge window" rule.

I think Linus is correct here and you are wrong. New code made to repair flaws that previously could not be repaired is definitely a new feature of the repair tool.

On the other hand, I am sympathetic to your argument that this is after all an experimental filesystem which has different needs from a stable hardware driver say, and as I recall the repair tool changes were entirely contained in the bcachefs subtree. As such, the worst it could do was to fail compilation on certain platforms, which already happened previously.

Personally I would have dropped the bugfix vs feature debate and focused on trying to get Linus to allow the repair code in as a new feature. From what I recall Linus said, you already burned some goodwill by the previous kernel compilation failure, but perhaps Linus could change his stance if you worked with him.

New features go in during RCs all the time.

The hard rule you're thinking of doesn't exist, it's all risk vs. reward.

If you had requested your code be rolled back to an earlier stable version as an alternative way of fixing the bug rather than merging unstable code you may have come to a compromise.

Reply on news.ycombinator.com