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

191–200 of 400 posts

Re: Bcachefs Goes to "Externally Maintained"

#191

Post by bionsystem »

yjftsjthsd-h wrote: post #92
ajross wrote: post #34

Earlier quoted context omitted.

Meh. This war was stale like nine years ago. At this point the originally-beaten horse has decomposed into soil. My general reply to this is: 1. The dm layer gives you cow/snapshots for any filesystem you want already and has for more than a decade. Some implementations actually use it for clever trickery like updates, even. Anyone who has software requirements in this space (as distinct from "wants to yell on the in…

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

The performance gain from compression (replacing IO with compute) is not ironic, it was seen as a feature for the various NAS that Sun (and after them Oracle) developped around ZFS.

Re: Bcachefs Goes to "Externally Maintained"

#192

Post by simoncion »

AaronFriel wrote: post #153
wtallis wrote: post #150

Earlier quoted context omitted.

> but it's silly to act like it's a paragon of stability in the kernel. And it's dishonest to act like bugs from 15 years ago justify present-tense claims that it is constantly eating people's data and is a bad joke. Nobody's arguing that btrfs doesn't have a past history of data loss, more than a decade ago; that's not what's being questioned here.

There's no need to call someone pointing out instability of a filesystem dishonest. That's bad faith. I don't get why folks feel the need to come out and cheer for a tool like this, do you have skin in the game on whether or not btrfs is considered stable? Are you a contributor? I don't get it. But since you asked - let me find some recent bugs. 5.15.37 - fixes data corruption in database reads using btrfs https://ww…

ext4 has "recent" correctness and corruption bugfixes. Just search through the 6.x and 5.x changelogs for "ext4:" to find them. It turns out that nontrivial filesystems are complex things that are hard to get right, even after decades of development by some of the most safety-and-correctness-obsessed people.

I've been using btrfs as the primary filesystem on my daily-driver PCs since 2009, 2010 or so. The only time I've had trouble with it was in the first couple of years I started using it. I've also used it as the primary FS on production systems at $DAYJOB. It works fine.

Re: Bcachefs Goes to "Externally Maintained"

#193

Post by procaryote »

saubeidl wrote: post #172
charcircuit wrote: post #158

Earlier quoted context omitted.

>the adult thing to do is not to simply disregard the rules The adult thing is to do best by the users. Critical file system bugs are worth blocking the release of any serious operating system in the real world as there is serious user impact. >Is that good for the users? I think it's complicated. It could allow for a faster release schedule for bug fixes which can allow for addressing file system issues faster.

I don't think getting the FS kicked out of the kernel is best by the users. Good engineering requires long term thinking.

There's more than bcachefs in the kernel. If dealing with bcachefs takes an inordinate amount of time and effort, dropping it is the right move.

I don't know the situation well enought to review where they drew the line, but there definitely should be a line somewhere.

Re: Bcachefs Goes to "Externally Maintained"

#194

Post by debazel »

icar wrote: post #187
qalmakka wrote: post #141

The whole situation is moronic at best. Linux needs a decent modern filesystem in tree. ZFS would easily be it, but unfortunately Sun decided back in the '00s to fuck Linux because they wanted to push Solaris instead. Little they knew ZFS ended up being FreeBSD top feature for years. Btrfs is constantly eating people data, it's a bad joke nowadays. Right now on Linux you're basically forced to constantly deal with ou…

I know it's not the same, but close enough for me: lvm + xfs works wonders and it's rock solid.

I would love to use xfs on my NAS setup but no checksums is a deal breaker. Checksums have saved me multiple times where I've been able to either repair files with parity or restore from backups.

Without checksums I would have overwritten my backup data and lost a ton of files because the drives were reported that everything was OK for months while writing corrupt files.

Re: Bcachefs Goes to "Externally Maintained"

#195

Post by saubeidl »

procaryote wrote: post #193
saubeidl wrote: post #172

Earlier quoted context omitted.

I don't think getting the FS kicked out of the kernel is best by the users. Good engineering requires long term thinking.

There's more than bcachefs in the kernel. If dealing with bcachefs takes an inordinate amount of time and effort, dropping it is the right move. I don't know the situation well enought to review where they drew the line, but there definitely should be a line somewhere.

That was my point exactly.

Re: Bcachefs Goes to "Externally Maintained"

#196

Post by abenga »

nextaccountic wrote: post #171
arp242 wrote: post #120

Earlier quoted context omitted.

Look, I get where you're coming from. It's not unreasonable. I've said this before. But there are also reasons why things are the way they are, and that is also not unreasonable. And at the end of the day: Linus is the boss. It really does come down to that. He has dozens of other subsystem maintainers to deal with and this is the process that works for him. Similar stuff applies to Debian. Personally, I deeply disli…

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

> It is unreasonable if it leads to users losing data.

Changing the kernel development process to allow adding new features willy-nilly late in the RC cycle will lead to much worse things than a few people using an experimental file system losing their data in the long term.

The process exists for a reason, and the kernel is a massive project that includes more than just one file system, no matter how special its developers and users believe it is.

Re: Bcachefs Goes to "Externally Maintained"

#197

Post by magicalhippo »

williamstein wrote: post #115
yjftsjthsd-h wrote: post #97

Earlier quoted context omitted.

> It's also much faster than ZFS at mounting a disk with a large number of filesystems (=subvolumes), which is critical for building certain types of fileservers at scale. Now you've piqued my curiosity; what uses that many filesystems/subvolumes? (Not an attack; I believe you, I'm just trying to figure out where it comes up)

It can be useful to create a file server with one filesystem/subvolume per user, because each user has their own isolated snapshots, backups via send/recv are user-specific, quotas are easier, etc. If you only have a few hundred users, ZFS is fine. But what if you have 100,000 users? Then just doing "zpool import" would take hours, whereas mounting a btrfs filesystem with 100,000 subvolumes takes a seconds. This comp…

I seem to recall some discussion in one of the OpenZFS leadership meetings about slow pool imports when you have many datasets. Sadly I can't recall the details, but at least it seems to be on their radar.

Re: Bcachefs Goes to "Externally Maintained"

#198

Post by bondant »

voidfunc wrote: post #160
qalmakka wrote: post #151

Earlier quoted context omitted.

> Btrfs is NOT constantly eating people data Tell it to my data then. I was 100% invested in Btrfs before 2017, the year where I lost a whole filesystem due to some random metadata corruption. I then started to move all of my storage to ZFS, which has never ever lost me a single byte of data yet despite the fact it's out of tree and stuff. My last Btrfs filesystem died randomly a few days ago (it was a disk in cold s…

2017 was 8 years ago...

8 years ago was the first time that person encountered a problem with btrfs. But that wasn’t the last apparently:

> My last Btrfs filesystem died randomly a few days ago

Re: Bcachefs Goes to "Externally Maintained"

#199

Post by rwmj »

nextaccountic wrote: post #171
arp242 wrote: post #120

Earlier quoted context omitted.

Look, I get where you're coming from. It's not unreasonable. I've said this before. But there are also reasons why things are the way they are, and that is also not unreasonable. And at the end of the day: Linus is the boss. It really does come down to that. He has dozens of other subsystem maintainers to deal with and this is the process that works for him. Similar stuff applies to Debian. Personally, I deeply disli…

> 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 want an install to be stable and predictable). Since distros are how you ultimately get your code into users' hands, it's really their way or the highway. Telling the distros they are wrong isn't going to go well.

Re: Bcachefs Goes to "Externally Maintained"

#200

Post by rwmj »

bornfreddy wrote: post #161
johnny22 wrote: post #76

Earlier quoted context omitted.

it's waaay simpler than that. Some projects have established rules, and kent doesn't want to follow them. It doesn't matter how nice (or not) he is.

I actually like the idea of the maintainer going out of his way to make sure that my filesystem is safe to use. Even if it goes against the established rules. And I'm saying that as someone who actually likes both Linux and Debian.

It's a strawman to imagine that Debian doesn't have a way to ensure filesystems are safe and to respond to critical bugs that might cause data corruption. It's just that you have to follow their rules to do it. (And broadly the same rules apply to the other big distros as well).
Post reply on HN