Live data from Hacker News

Bcachefs Goes to "Externally Maintained"

lwn.net

241–250 of 400 posts

Re: Bcachefs Goes to "Externally Maintained"

#241
post #213
post #207

Earlier quoted context omitted.

It could be a long term strategy by Oracle to be able to sue IBM and other big companies distributing Linux with ZFS built in. If Oracle want people to use ZFS they can just relicense the code they have copyright on.

Oracle does not have copyright on OpenZFS code - only on the version in Solaris. The code in OpenZFS and Solaris has diverged after Oracle closed OpenSolaris.

> The code in OpenZFS and Solaris has diverged after Oracle closed OpenSolaris.

Diverged. Not rewritten entirely.

Re: Bcachefs Goes to "Externally Maintained"

#242
post #61
post #23

Earlier quoted context omitted.

Seriously for the people who take filesystems seriously and have strong preferences... Multi disk might be important.

BTRFS does have stable, usable multi-disk support. The RAID 0, 1, and 10 modes are fine. I've been using BTRFS RAID1 for over a decade and across numerous disk failures. It's by far the best solution for building a durable array on my home server stuffed full of a random assortment of disks—ZFS will never have the flexibility to be useful with mismatched capacities like this. It's only the parity RAID modes that BTRF…

That’s nice and all, but I have five disks in my server. I want the 6 mode.

In practice RAIDZ2 works great.

Re: Bcachefs Goes to "Externally Maintained"

#243

Earlier quoted context omitted.

This was a bug fix. My point is that there will always be bugs in the kernel so not all bugs are worth blocking a release, but losing data is worth blocking the release for. >"Experimental" label EXACTLY to prevent this stuff from blocking release 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…

> 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…

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.

Re: Bcachefs Goes to "Externally Maintained"

#244
post #104

Earlier quoted context omitted.

To list down the current state of things: 1. Regardless of whether correct or not, it's Linus that decides what's a feature and what's not in Linux. Like he has for the last however many decades. Repair code is a feature if Linus says it is a feature. 2. Being correct comes second to being agreeable in human-human interactions. For example, dunking on x file system does not work as a defense when the person opposite…

When rules and authority start to take precedence over making sure things work, things have gone off the rails and we're not doing engineering anymore.

Collaborative projects don't work on pure engineering. There are significant resource management components that basically amount to therapy, psychiatry, and side show entertainment because the most critical resources are human minds.

Excellent engineering management largely isolates engineers from having to deal with this non-engineering stuff (except for the subset that is specifically for their own personal benefit)-- but open source tends to radically flatten organizations that produce software, such that every contributor must also be their own manager to a great degree.

In a well run project you don't necessarily have to be good at or even interested in all the more socially oriented components of the project organization. But if you're not you must be willing to let someone else handle that stuff and go along with their judgements even if they seem suboptimal from the narrower perspective you've adopted. If you can't then from a "collaborative development as a system" view you're a faulty component that doesn't provide the right interface for the system's requirements (and are gonna get removed!). :)

Another way to look at it is that it would be ideal if every technical element were optimal at all times. In small systems with well understood requirements this can be possible or at least close to possible. But in big complex and poorly scoped systems it's just not possible: We have imperfect information, there are conflicting requirements, we have finite time, and so on. The system as a whole will always be far from perfect. If anyone tried to make it all perfect it would just fail to make progress, deadlock, or otherwise. The management of the project is always trying to balance the imperfections. They know that their decisions are often making things worse for a local concern, but they do so with belief that over time the decisions result in a better system overall. Linux has a good reputation in large part due to a long history of making good decisions about the flaws to accept or even introduce, which issues to gloss over vs debate to death.

Re: Bcachefs Goes to "Externally Maintained"

#245

Earlier quoted context omitted.

> Compression seems silly in the modern world. Virtually everything is already compressed. IIRC my laptop's zpool has a 1.2x compression ratio; it's worth doing. At a previous job, we had over a petabyte of postgres on ZFS and saved real money with compression. Hilariously, on some servers we also improved performance because ZFS could decompress reads faster than the disk could read.

How do you get a PostgreSQL database to grow to one petabyte? The maximum table size is 32 TB o_O

Cumulative; dozens of machines with a combined database size over a PB even though each box only had like 20 TB.

Re: Bcachefs Goes to "Externally Maintained"

#246
post #224

Earlier quoted context omitted.

No, the problem wasn't following the rules. The patch that kicked off the current conflict was the 'journal_rewind' patch; we recently (6.15) had the worst bug in the entire history upstream - it was taking out entire subvolumes. The third report got me a metadata dump with everything I needed to debug the issue, thank god, and now we have a great deal of hardening to ensure a bug like this can never happen again. Su…

It's so sad to see an excellent engineer such as yourself, building what seems like an excellent filesystem that has the potential to be better than everything else available for Linux for many use cases, completely fail to achieve your goals because you lack the people skills to navigate working as a part of a team under a technical leader. Every comment and e-mail I've seen from you has demonstrated an impressive l…

I get a ton of comments like this.

Pointing the finger at the skills I lack and my inability, while ignoring the wider picture, of the kernel burning out maintainers and not doing well on filesystems.

It's wearying.

Re: Bcachefs Goes to "Externally Maintained"

#247
post #223
post #127

Earlier quoted context omitted.

There's literally ZFS-on-linux and it works great. And yes, I will once again say Linus is completely wrong about ZFS and the multiple times he's spoken about it, it's abundantly clear he's never used it or bothered to spend any time researching its features and functionality. https://zfsonlinux.org/

To me, ZFS on Linux is extremely uninteresting except for the specific use case of a NAS with a bunch of drives. I don't want to deal with out-of-tree filesystems unless I absolutely have to. And even on a NAS, I would want the root partition to be ext4 or btrfs or something else that's in the kernel.

> the specific use case of a NAS with a bunch of drives

Aka a way bigger part of the industry than it should probably still be ;)

Re: Bcachefs Goes to "Externally Maintained"

#248

Earlier quoted context omitted.

>sneak a new features in RC Too solve a bug with the filesystem that people in the wild were hitting. Like how Linus has said in the past with how there is a blurry line between security fixes and bug fixes. There is a blurry line between filesystem bugs and recovery features. If you read the email it is clear that the full feature has more work needed and this is more of a basic implementation to address bugs that p…

> Too solve a bug with the filesystem that people in the wild were hitting. So you acknowledge that this last episode involved trying to push new features into a RC. As it was made abundantly clear, not only is the point of RC branches to only get tiny bugfixes after testing, the feature work that was presented was also untested and risked introducing major regressions. All these red flags were repeatedly raised in t…

No, I'm sorry but you're simply wrong.

bcachefs has a ton of QA, both automated testing and a lot of testers that run my latest and I work with on a daily basis. The patch was well tested; it was for codepaths that we have good regression tests for, it was algorithmically simple, and it worked perfectly to recover a filesystem from the original bug report, and it performed flawlessly again not long after.

I've explained my testing and QA on the lists multiple times.

You, like the other kernel maintainers in that thread, are making wild assertions despite having no involvement with the project.

Re: Bcachefs Goes to "Externally Maintained"

#249
post #64

Earlier quoted context omitted.

> it doesn't really communicate why Kent's actions are problematic I agree that the kernel community can be a hostile environment. Though I’d argue that people _have_ tried to explain things to Kent, multiple times. At least a few have been calm, respectful attempts. Sadly, Kent responds to everything in an email except the key part that is being pointed out to him (usually his behavior). Or deflects by going on the…

> Sadly, Kent responds to everything in an email except the key part that is being pointed out to him (usually his behavior). Behaviour sounds like the least important part of code contributions. I smell overpowered, should've-been-a-kindergarten-teacher code of conduct person overreach.

No, Kent has generally had a nice tone. The issue is that he has repeatedly violated the rules about code contributions. For example by including new features together with several bug-fixes during rc. That is not a CoC issue, it is not respecting the rules of patch submission and not respecting the time of the kernel maintainers.

Re: Bcachefs Goes to "Externally Maintained"

#250
post #104

Earlier quoted context omitted.

To list down the current state of things: 1. Regardless of whether correct or not, it's Linus that decides what's a feature and what's not in Linux. Like he has for the last however many decades. Repair code is a feature if Linus says it is a feature. 2. Being correct comes second to being agreeable in human-human interactions. For example, dunking on x file system does not work as a defense when the person opposite…

> Being correct comes second to being agreeable in human-human interactions Prioritizing agreeableness above correctness is the reason the space shuttle Challenger blew up. The bcachefs fracas is interesting and important because it's like a stain making some damn germ's organelles visible: it highlights a psychological division in tech and humanity in general between people who prioritize 1) deferring to authority,…

Thanks, I've been struggling to put this into words.

When you're working on the core technology we all depend on, correctness is not optional.

Post reply on HN