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

61–70 of 400 posts

Re: Bcachefs Goes to "Externally Maintained"

#61

Post by wtallis »

NewJazz wrote: post #23
betaby wrote: post #18

Earlier quoted context omitted.

But RAID-6 is the closest approximation to raid-z2 from ZFS! And raid-z2 is stable for a decade+. Indeed btrfs works just fine on my laptop. My point is that Linux lacks ZFS-like fs for large multi disc setups.

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 BTRFS lacks, and that's a real disadvantage but is hardly the whole story.

Re: Bcachefs Goes to "Externally Maintained"

#62

Post by wtallis »

AaronFriel wrote: post #17
LeoPanthera wrote: post #14

Earlier quoted context omitted.

It's sort of frustrating that this constantly comes up. It's true that btrfs does have issues with RAID-5 and RAID-6 configurations, but this is frequently used (not necessarily by you) as some kind of gotcha as to why you shouldn't use it at all. That's insane. I promise that disk spanning issues won't affect your use of it on your tiny ThinkPad SSD. It's important to note that striping and mirroring works just fine…

Respectfully to the maintainers: How can this be a stable filesystem if parity is unstable and risks data loss? How has this been allowed to happen? It just seems so profoundly unserious to me.

Does the whole filesystem need to be marked as unstable if it has a single experimental feature? Is any other filesystem held to that standard?

Re: Bcachefs Goes to "Externally Maintained"

#63

Post by ajross »

anon-3988 wrote: post #36
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…

> Filesystems are a solved problem. If ZFS disappeared from the world today... really who would even care? Only those of us still around trying to shout on the internet. Yeah nah, have you tried processing terabytes of data every day and storing them? It gets better now with DDR5 but bit flips do actually happen.

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.

Re: Bcachefs Goes to "Externally Maintained"

#64

Post by sevg »

ajb wrote: post #59
sevg wrote: post #9

Is it just me or does Kent seem self-destructively glued to his own idea of how kernel development should work? I don’t doubt that people on all sides have made mis-steps, but from the outside it mostly just seems like Kent doesn’t want to play by the rules (despite having been given years of patience).

I think Kent is in the wrong here, but it really doesn't help that the kernel people from Linus on down are seemingly unable to explain the problem, and instead resort to playground insults. Apart from being unprofessional and making for a hostile work environment, it doesn't really communicate why Kent's actions are problematic, so I've some sympathy for his not believing that they are.

> 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 attack. And generally refuses to apologise.

Re: Bcachefs Goes to "Externally Maintained"

#65

Post by bornfreddy »

sevg wrote: post #9

Is it just me or does Kent seem self-destructively glued to his own idea of how kernel development should work? I don’t doubt that people on all sides have made mis-steps, but from the outside it mostly just seems like Kent doesn’t want to play by the rules (despite having been given years of patience).

Being an outsider to this whole scene, the whole thread reads very differently to me.

Kent seems very patient in explaining his position (and frustrations arising from other people introducing bugs to his code) and the kernel & debian folks are performing a smearing campaign instead of replying to what I see are genuine problems in the process. As an example, the quotes that are referenced by user paravoid are, imho, taken out of context (judging by reading the provided links).

There probably is a lot more history to it, but judging from that thread it's not Kent who looks like a bad guy.

Re: Bcachefs Goes to "Externally Maintained"

#66

Post by dmm »

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

btrfs is fine for single disks or mirrors. In my experience, the main advantages of zfs over btrfs is that ZFS has production ready raid5/6 like parity modes and has much better performance for small sync writes, which are common for databases and hosting VM images.

Re: Bcachefs Goes to "Externally Maintained"

#67

Post by fluidcruft »

ajross wrote: post #34
doubletwoyou wrote: post #31

Earlier quoted context omitted.

This might not be directly about btrfs but bcachefs zfs and btrfs are the only filesystems for Linux that provide modern features like transparent compression, snapshots, and CoW. zfs is out of tree leaving it as an unviable option for many people. This news means that bcachefs is going to be in a very weird state in-kernel, which leaves only btrfs as the only other in-tree ‘modern’ filesystem. This news about bcache…

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…

One feature I like about ZFS and have not seen elsewhere is that you can have each filesystem within the pool use its own encryption keys but more importantly all of the pool's data integrity and maintenance protection (scrubs, migrations, etc) work with filesystems in their encrypted state. So you can boot up the full system and then unlock and access projects only as needed.

The dm stuff is one key for the entire partition and you can't check it for bitrot or repair it without the key.

Re: Bcachefs Goes to "Externally Maintained"

#68

Post by sarlalian »

ffsm8 wrote: post #42
WD-42 wrote: post #26

Earlier quoted context omitted.

The article says that bcachefs is not being removed from the mainline kernel. This looks like mostly a workaround for Linus and other kernel devs to not have to deal with Kent directly.

The three listed options in the OP thread were * Another kernel Dev takes over management and they tread it as a fork (highly unlikely according to their estimate) * Kent hires someone to upstream the changes for him and Kent stops complaining wrt when it's getting merged * Bcachefs gets no maintenance and will likely be removed in the next major release I do not know him personally, but most interactions I've read o…

If you look at all the places where Kent has had drama, the common element is him and environments that have pretty rigid workflows. The common thread seems to be him not respecting workflows and processes that those places have, that inconvenience his goals. So, he ignores the workflows and processes of those places, and creates a constant state of friction and papercuts for those who he needs to accomplish his goals. They eventually get fed up, and either say no, not working with you anymore, or no, you’re not welcome to contribute here anymore.

He’s not super offensive, but he will tell a Debian package maintainer that their process sucks, and the should change it and they are being stupid by following that process. Overall, he seems a bit entitled, and unwilling to compromise with others. It’s not just Kent though, the areas that seem to be the most problematic for him, are when it’s an unstoppable force (Kent), and an immovable wall (Linux / Debian).

Working in the Linux kernel is well known for its frustrations and the personal conflict that it creates, to the point that there are almost no linux kernel devs/maintainers that aren’t paid to do the work. You can see a similar set of events happen with Rust4Linux people, Asahi linux project and their R4L drivers, etc.

Re: Bcachefs Goes to "Externally Maintained"

#69

Post by uecker »

Who would use a file system which essentially seems to be developed by a single person? A bus-factor of one seems unacceptable for a FS. But maybe I am wrong and there are other developers, then why do they not take over upstreaming if the main developer is unable to collaborate with the kernel community.

Re: Bcachefs Goes to "Externally Maintained"

#70

Post by ajross »

toast0 wrote: post #56
bombcar wrote: post #48

Earlier quoted context omitted.

Bit flips can happen, and if it’s a problem you should have additional verification above the filesystem layer, even if using ZFS. And maybe below it. And backups. Backups make a lot of this minor.

Backups are great, but don't help much if you backup corrupted data. You can certainly add verification above and below your filesystem, but the filesystem seems like a good layer to have verification. Capturing a checksum while writing and verifying it while reading seems appropriate; zfs scrub is a convenient way to check everything on a regular basis. Personally, my data feels important enough to make that level o…

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 Amazon and buy an exfat stick, whatever. By far the most important thing you're ever going to do for your data is Back. It. Up.

Filesystem choice is, and I repeat, very much a yell-on-the-internet kind of thing. It makes you feel smart on HN. Backups to junky Chinese flash sticks are what are going to save you from losing data.

Post reply on HN