Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Bcachefs Goes to "Externally Maintained"

lwn.net

Post reply on HN
Print view View original

201–210 of 400 posts

Re: Bcachefs Goes to "Externally Maintained"

#201

Post by justincormack »

khimaros wrote: post #110
ajross wrote: post #63

Earlier quoted context omitted.

And once more, you're positing the lack of a feature that is available and very robust (c.f. "yell on the internet" vs. "discuss solutions to a problem"). You don't need your filesystem to integrate checksumming when dm/lvm already do it for you.

i'm not one for internet arguments and really just want solutions. maybe you could point me at the details for a setup that worked for you? based on my own testing, dm has a lot of footguns and, with some kernels, as little as 100 bytes of corruption to the underlying disk could render a dm-integrity volume completely unusable (requiring a full rebuild) https://github.com/khimaros/raid-explorations

Well the intention of the integrity things is to preserve integrity that is an explicit choice, in particular for encrypted data. You definitely need a backup strategy.

Re: Bcachefs Goes to "Externally Maintained"

#202

Post by petre »

ofrzeta wrote: post #28
betaby wrote: post #12

The sad part, that despite the years of the development BTRS never reached the parity with ZFS. And yesterday's news "Josef Bacik who is a long-time Btrfs developer and active co-maintainer alongside David Sterba is leaving Meta. Additionally, he's also stepping back from Linux kernel development as his primary job." see https://www.phoronix.com/news/Josef-Bacik-Leaves-Meta There is no 'modern' ZFS-like fs in Linux n…

Suse Linux Enterprise still uses Btrfs as the Root-FS, so it can't be that bad, right? What is Chris Mason actually doing these days? I did some googling and only found out that he was working on a tool called "rsched".

We use OpenSuSE and I always switch the installs to ext4. No fancy features, but always works, doesn't lose my root fs.

Re: Bcachefs Goes to "Externally Maintained"

#203

Post by arccy »

gdgghhhhh wrote: post #167

It's amazing how many of the "experts" here don't get that bcachefs != btrfs

people understand they're different, but if bcachefs is out, then that leaves btrfs as the only modern in-tree filesystem, but apparently you can't trust it with important data either.

Re: Bcachefs Goes to "Externally Maintained"

#204

Post by chao- »

evanjrowley wrote: post #129
tw04 wrote: 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/

Sometimes I wonder how someone so talented could be so wrong about ZFS, and it makes me wonder if his negative responses to ZFS discussions could be a way of creating plausible deniability in case Oracle's lawyers ever learn how to spell ZFS.

How many years has it been since Ubuntu started shipping ZFS, purportedly in violation of whatever legal fears the kernel team has? Four years? Five years?

I obviously have nothing like inside knowledge, but I assume the reason there have not been lawsuits over this, is that whoever could bring one (would it be only Oracle?) expects there are even-odds that they would lose? Thus the risk of setting an adverse precedent isn't worth the damages they might be awarded from suing Canonical?

Re: Bcachefs Goes to "Externally Maintained"

#205

Post by petre »

toast0 wrote: post #98
ajross wrote: post #70

Earlier quoted context omitted.

FWIW, framed the way you do, I'd say the block device layer would be an *even better* place for that validation, no? > Personally, my data feels important enough to make that level of effort, but not important enough to do anything else. OMG. Backups! You need backups! Worry about polishing your geek cred once your data is on physically separate storage. Seriously, this is not a technology choice problem. Go to Amazo…

I apprechiate the argument. I do have backups. Zfs makes it easy to send snapshots and so I do. But I don't usually verify the backups, so there's that. And everything is in the same zip code for the most part, so one big disaster and I'll lose everything. C'est la vie.

What good is a backup if you can't restore it?

Re: Bcachefs Goes to "Externally Maintained"

#206

Post by nextaccountic »

rwmj wrote: post #199
nextaccountic wrote: post #171

Earlier quoted context omitted.

> But there are also reasons why things are the way they are, and that is also not unreasonable. It is unreasonable if it leads to users losing data. At this point, the only reasonable thing is to either completely remove support for bcachefs or give timely fixes for critical bugs, there's no middle position that won't willfully lead to users losing their data. This used to be the default for distributions like Debia…

Not too familiar with the kernel process for this, but for Linux distros there are ways to respond to critical issues including data corruption and data loss. It's just that you have to follow their processes to do this, such as producing a minimal patch that fixes the problem which is backported into the older code base (and there's a reason for that too: end users don't want churn on their installed systems, they w…

For the Debian thing, I'm not sure on the specifics for bcachefs-progs (I'm going by what the author is reporting and some blog posts) but I think the problem with Debian is that they willfully ignore when upstream says "this is only compatible with this library version 2.1.x" and will downgrade or upgrade the library into not supported versions, to match the versions used in other programs already packaged. This kind of thing can introduce subtle, hard to debug bugs. It's a mess and problems are usually reported to upstream, that's a recurrent problem for Rust programs packaged in Debian. Rust absolutely isn't this language where if it compiles, it works, no matter how much people think otherwise.

And this is happening even though it's common for Debian to package the same C library multiple times, like, libfuse2 and libfuse3. This could be done for Rust libraries if they wanted to.

Anyway see the discussion and the relevant article here https://news.ycombinator.com/item?id=41407768 and https://jonathancarter.org/2024/08/29/orphaning-bcachefs-too...

Re: Bcachefs Goes to "Externally Maintained"

#207

Post by tuna74 »

chao- wrote: post #204
evanjrowley wrote: post #129

Earlier quoted context omitted.

Sometimes I wonder how someone so talented could be so wrong about ZFS, and it makes me wonder if his negative responses to ZFS discussions could be a way of creating plausible deniability in case Oracle's lawyers ever learn how to spell ZFS.

How many years has it been since Ubuntu started shipping ZFS, purportedly in violation of whatever legal fears the kernel team has? Four years? Five years? I obviously have nothing like inside knowledge, but I assume the reason there have not been lawsuits over this, is that whoever could bring one (would it be only Oracle?) expects there are even-odds that they would lose? Thus the risk of setting an adverse precede…

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.

Re: Bcachefs Goes to "Externally Maintained"

#208

Post by rwmj »

nextaccountic wrote: post #206
rwmj wrote: post #199

Earlier quoted context omitted.

Not too familiar with the kernel process for this, but for Linux distros there are ways to respond to critical issues including data corruption and data loss. It's just that you have to follow their processes to do this, such as producing a minimal patch that fixes the problem which is backported into the older code base (and there's a reason for that too: end users don't want churn on their installed systems, they w…

For the Debian thing, I'm not sure on the specifics for bcachefs-progs (I'm going by what the author is reporting and some blog posts) but I think the problem with Debian is that they willfully ignore when upstream says "this is only compatible with this library version 2.1.x" and will downgrade or upgrade the library into not supported versions, to match the versions used in other programs already packaged. This kin…

But that's exactly the point here. In the context of a whole distribution, you don't want to update some package to a new version (on a stable branch), because that would affect lots of other packages that depended on that one. It may even be that other packages cannot work with the new updated dependency. Even if they can, end users don't want versions to change greatly (again, along a stable branch). Upstreams should accept this reality and ensure they support the older libraries as far as possible. Or they can deny reality and then we get into this situation.

And carrying multiple versions is problematic too as it causes increased burdens for the downstream maintainers.

I'd argue that libfuse is a bit of a special case since the API between 2 & 3 changed substantially, and not all dependencies have moved to version 3 (or can move, since if you move the v3 then you break on other platforms like BSD and macOS that still only support the v2 API).

Rust and especially Golang are both a massive pile of instability because the developers don't seem to understand that long term stable APIs are a benefit. You have to put in a bit of care and attention rather than always chasing the new thing and bundling everything.

Re: Bcachefs Goes to "Externally Maintained"

#209

Post by tarruda »

koverstreet wrote: post #142
tarruda wrote: post #137

Earlier quoted context omitted.

It is not good when politics get in the way of good engineering. Regardless of differing points of view on the situation, I think everyone can agree that bcachefs being actively updated on Linus tree is a good thing, right? If you were able to work at your own pace, and someone else took the responsibility of pulling your changes at a pace that satisfies Linus, wouldn't that solve the problem of Linux having a good m…

At this time, I don't think so. We were never able to get any sane and consistent policy on bugfixes, and I don't have high hopes that anyone else will have better luck. The XFS folks have had their own issues with interference, leading to burnout - they're on their third maintainer, and it's really not good for a project to be cycling through maintainers and burning people out, losing consistency of leadership and i…

Keep in mind that bcachefs’s adoption and eventual mainstream acceptance are not contingent on Linus accepting your contributions or on you “removing the experimental label.” What matters is eliminating the barriers that prevent users from trying it, and that is far easier when bcachefs is an upstream filesystem—something that allows more distributions to offer it as an installer option.

> And I'm still seeing Linus lashing out at people on practically a weekly basis. I could never ask anyone else to have to deal with that.

This is a bit off‑topic, but I wouldn’t be so quick to judge how well Linus is doing his job; no one else in the world has his responsibilities.

At this point, any new kernel contributor should be familiar with Linus and have come to accept, or at least tolerate, his ways.

> I think the kernel community has some things they need to figure out before bcachefs can go back in.

Fair enough. It may be better to let things cool off while giving bcachefs more time to reach a stable state before attempting to reintegrate it into Linux development. I hope you won’t give up, because Linux needs this.

Since bcachefs is your project and you seem to enjoy working on it, it wouldn’t be a stretch to say that you need this too, right? Don’t let ego get in the way of achieving your goals.

Re: Bcachefs Goes to "Externally Maintained"

#210

Post by p_l »

koverstreet wrote: post #136
tw04 wrote: 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/

ZFS deserves an absolutely legendary amount of respect for showing us all what a modern filesystem should be - the papers they wrote, alone, did the entire filesystem world such a massive service by demonstrating the possibilities of full data integrity and why we want it, and then they showed it could be done. But there's a ton of room for improvement beyond what ZFS did. ZFS was a very conservative design in a lot…

Can you explain your definition of "extent"? Because under every definition I dealt with in filesystems before, ZFS is extent based at the lower layer, and flat out object storage system (closer to S3) at upper layer.
Post reply on HN