Hacker News Reader

Comment by rewgs | Hacker News Reader

Kent, it’s actually really simple: bcachefs is experimental. Those that are currently using bcachefs and those that can’t wait for a data recovery tool that hasn’t existed until now is a group containing precisely zero people.

You’re acting like bcachefs systems are storing Critical Data That Absolutely Cannot Be Lost. And yet at the same time it’s experimental. I’m just one user, but I can tell you that, even as excited as I am about bcachefs, I’m not touching it with a ten foot pole for anything beyond playing around until at least the experimental label is removed.

I imagine my position is not uncommon.

Please stop trying to die on this hill. Your project is really great and really important. I want it to succeed.

Just chill and let bug fixes be bug fixes and features be features.

View on HN

I've recovered a _lot_ of data for users that didn't have backups.

It's all part of the job.

Frankly, if you store important data on an experimental file system and don’t have backups, you deserve to lose it.

And I have to imagine that those that are technical enough to not only use Linux, but use an experimental non-default file system, and those that don’t have backups of their data, is a vanishingly small group.

So no, I actually disagree —- it’s not part of the job.

So again we arrive at the same place: this data recovery tool is not worth the drama.

It’s a feature, not a bug fix, and an incredibly unimportant one at that _at this stage of development_. If bcachefs weren’t experimental and were widely used, it would be a different story —- I’d probably be in favor of bending the rules to get it in there faster. But that just isn’t where we are right now.

If you have a lot of users who store data on an experimental filesystems and who don't back up said data, yet are not cool with data losses, I would say you have a serious communication issue at hand.

I have lost years of my work due to not having proper backups. I know the pain.

And I totally get you feel responsible for the data loss and want to help your users, I'm like that too with my code.

But this is an experiment. It's right there in the name.

If this feature really is as needed as you claim here, then getting it into the kernel is a mere side-issue.

In that case, your #1 priority should be to fix whatever is causing such users to install and use bcachefs without having a recovery plan that they have verified, and get existing users on the same level.

Because not doing so would be a huge disservice to those users who don't know better, and at worst borderline exploitative.

Writing recovery software is part of the job. Forcing it into the kernel to save users who are clearly not in any shape or form competent enough to partake in your experiment is definitely not part of the job.

Finding yourself in this position means something has gone very, very wrong.

> Forcing it into the kernel to save users who are clearly not in any shape or form competent enough to partake in your experiment is definitely not part of the job.

That code needs to be there for non-experimental users later on.

The reason to push it in quickly is so it can get tested and iterated on. Saving a handful of experimental users is not the main benefit.

> Saving a handful of experimental users is not the main benefit.

Kent himself argued otherwise here[1].

And even if that were the case, there's no need to take a stand on trying to get it into the kernel. If he gets booted out of the kernel tree, then the end result is the same for his users: they have to compile their own kernel. So it makes no sense to push this so hard.

[1]: https://www.phoronix.com/forums/forum/software/general-linux...

> Kent himself argued otherwise here[1].

I said "main" for a reason. The current users that need to recover data are a part of the picture, but they're a few trees out of the forest.

"Please tell that to the users who lost data." is not arguing against what I said.

> And even if that were the case, there's no need to take a stand on trying to get it into the kernel. If he gets booted out of the kernel tree, then the end result is the same for his users: they have to compile their own kernel. So it makes no sense to push this so hard.

He's not giving an ultimatum here. The goal is to figure out something that works for everyone.

> The reason to push it in quickly is so it can get tested and iterated on. Saving a handful of experimental users is not the main benefit.

Testing and iterating on code does not require making exceptions to the kernel development schedule.

He makes a pretty good argument that the filesystem's never going to get done if there's only one iteration per kernel release.

I don't know what the best solution is, but it looks like it requires either exceptions or something else that gets around the schedule.

Well... there is the merge window where this should be added and then like 8 release candidates (as always: it depends) where he can iterate on the added code. So the statement of "only one iteration per kernel release" is just categorically wrong.

"categorically wrong" is a rather uncharitable way to describe you and me using different connotations of the word "iterate". Especially when you pulled "on the added code" out of nowhere.

To stabilize the filesystem he needs to iterate on the code that has been there for a while, to add more debugging and fallbacks for error situations. In this case he wanted to add a new fallback.

> You’re acting like bcachefs systems are storing Critical Data That Absolutely Cannot Be Lost.

It is to the user storing it.

As I said in my reply to Kent: frankly, if you store important data on an experimental file system and don’t have backups, you deserve to lose it.

Reply on news.ycombinator.com