> In practice bcachefs is used in production with real users. If the experimental label prevents critical bug fixes from making it into the kernel then it would be better to just remove that label.

alternative perspective: those users have knowingly and willingly put experimental software into production. it was their choice, they were informed of the risk and so the consequences and responsibility are their’s.

it’s like signing up to take some experimental medicine, and then complaining no-one told me about the side-effect of persistent headaches.

that doesn’t stop anyone from being user-centric in their approach, e.g. call me if you notice any symptoms and i’ll come round your house to examine you.

… as long as everyone is clear about the fact it is experimental and the boundaries/limitations that apply, e.g. there will be certain persistent headache medicines that cannot be prescribed to you, or it might take longer for them to work because you’re on an experimental medicine.

▲

koverstreet 3 days ago | parent [-]

Again: the elephant in the room is that a lot of bcachefs users are using it explicitly because they have lost a lot of data on btrfs, and they've found it to be more trustworthy.

This puts us all in a shitty situation. I want the experimental label to come off at the right time - when every critical bug is fixed and it's as trustworthy as I can reasonably make it, when I know according to the data I have that everyone is going to have a good experience - but I have real users who need this thing and need to be supported.

There is _no reason_ to interpret the experimental label in the way that you're saying, you're advocating that reliability for the end user be deprioritized versus every other filesystem.

But deprioritizing reliability is what got us into this mess.

▲

rob_c 3 days ago | parent [-]

>users are using it explicitly because they have lost a lot of data on btrfs

PLEASE, honestly, EDUCATE THESE USERS. This is still marked experimental for numerous reasons regardless of the 'planned work for 6.18'. Users who can't suffer any data loss and are repeating their mistake of using btrfs shouldn't be using a none default/standard/hardened filesystem period.

▲

koverstreet 3 days ago | parent [-]

No, really. People aren't losing data on bcachefs. We still have minor hiccups that do affect usability, and I put a lot of effort into educating users about where we're at and what to expect.

In the past I've often told people who wanted to migrate off of btrfs "check back in six months", but I'm not now because 6.16 is looking amazingly solid; all the data I have says that your data really is safer on bcachefs than btrfs.

I'm not advocating for people to jump from ext4/xfs/zfs, that needs more time.

▲

trueismywork 3 days ago | parent [-]

You're arguing in circles. Either bcachefs is experimental and hence needs a lot of changes and tools to make sure that users dont lose data and hence the fixes are not critical/users can use a custom branch. Or it is stable and the only thing users need is actual big fixes. Not new tools in an RC3.

Don't compare bcachefs with btrfs for stability. Compare it with ext4. (And dont care anecdotal data, compare the process).

▲

koverstreet 3 days ago | parent [-]

So, are we agreeing that btrfs isn't fit for purpose, then?

	▲	yencabulator 2 days ago \| parent \| next [-]
		Kent, whenever you're at a point where you could make a good decision and make progress on any non-technical axis, you choose to attack something or someone. This is why you're getting the reactions you are getting. bcachefs design looks good, literally everything else about the project is miserable, because of this. Now, I fully expect you to react poorly to this message, too. That is the expectation the world has formed of you. Think about that.
	▲	trueismywork 3 days ago \| parent \| prev [-]
		I don't understand your question. Are you going somewhere with this?