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

91–100 of 400 posts

Re: Bcachefs Goes to "Externally Maintained"

#91

Post by yjftsjthsd-h »

ajross wrote: post #63
anon-3988 wrote: post #36

Earlier quoted context omitted.

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

> You don't need your filesystem to integrate checksumming when dm/lvm already do it for you.

https://wiki.archlinux.org/title/Dm-integrity

> It uses journaling for guaranteeing write atomicity by default, which effectively halves the write speed

I'd really rather not do that, thanks.

Re: Bcachefs Goes to "Externally Maintained"

#92

Post by yjftsjthsd-h »

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…

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

Re: Bcachefs Goes to "Externally Maintained"

#93

Post by yjftsjthsd-h »

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

I used btrfs a few years ago, on OpenSUSE, because I also thought that would work, and it was on a single disk. It lost my root filesystem twice.

Re: Bcachefs Goes to "Externally Maintained"

#94

Post by commandersaki »

uecker wrote: post #69

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.

I did for my laptop and Raspberry Pi which I didn't care much about. It was great being able to interact with Kent over IRC to sort out problems and when he is actually available he's really helpeful, but it made me realise that bcachefs has a long ways to go, and I have come to the realisation bus factor 1 is not something I'd want long term.

Re: Bcachefs Goes to "Externally Maintained"

#95

Post by ajross »

nh2 wrote: post #90
ajross wrote: post #88

Earlier quoted context omitted.

I didn't really think it was that bad? But sure, point taken. My goal was actually the same though: to try to short-circuit the inevitable platform flame by calling it out explicitly and pointing out that the technical details are sort of a solved problem. ZFS argumentation gets exhausting, and has ever since it was released. It ends up as a proxy for Sun vs. Linux, GNU vs. BSD, Apple vs. Google, hippy free software…

How can I, with dm/lvm: * For some detected corruption, be told directly which files are affected? * Get filesystem level snapshots that are guaranteed to be consistent in the way ZFS and CephFS snapshots guarantee?

On urging from tptacek I'll take that seriously and not as flame:

1. This is misunderstanding how device corruption works. It's not and can't ever be limited to "files". (Among other things: you can lose whole trees if a directory gets clobbered, you'd never even be able to enumerate the "corrupted files" at all!). All you know (all you can know) is that you got a success and that means the relevant data and metadata matched the checksums computed at write time. And that property is no different with dm. But if you want to know a subset of the damage just read the stderr from tar, or your kernel logs, etc...

2. Metadata robustness in the face of inconsistent updates (e.g. power loss!) is a feature provided by all modern filesystems, and ZFS is no more or less robust than ext4 et. al. But all such filesystems (ZFS included) will "lose data" that hadn't been fully flushed. Applications that are sensitive to that sort of thing must (!) handle this by having some level of "transaction" checkpointing (i.e. a fsync call). ZFS does absolutely nothing to fix this for you. What is true is that an unsynchronized snapshot looks like "power loss" at the dm level where it doesn't in ZFS. But... that's not useful for anyone that actually cares about data integrity, because you still have to solve the power loss problem. And solving the power loss problem obviates the need for ZFS.

Re: Bcachefs Goes to "Externally Maintained"

#96

Post by BoredPositron »

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…

Grounded? Not offensive?

https://lore.kernel.org/lkml/CAHk-=wiLE9BkSiq8F-mFW5NOtPzYrt...

https://lore.kernel.org/all/citv2v6f33hoidq75xd2spaqxf7nl5wb...

Re: Bcachefs Goes to "Externally Maintained"

#97

Post by yjftsjthsd-h »

williamstein wrote: post #43
deknos wrote: post #37

Earlier quoted context omitted.

i run btrfs on servers and desktops. it's usuable.

So do I and BTRFS is extremely good these days. 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. In contrast, ZFS scales horribly as the number of filesystems increases, where btrfs seems to be O(1). btrfs's quota functionality is also much better than it used to be (and very flexible), after all t…

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

Re: Bcachefs Goes to "Externally Maintained"

#98

Post by toast0 »

ajross wrote: post #70
toast0 wrote: post #56

Earlier quoted context omitted.

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

Re: Bcachefs Goes to "Externally Maintained"

#99

Post by dralley »

philipallstar wrote: post #82
sevg wrote: 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. As someone who likes bcachefs and even literally donates to Kent's patreon, the way he has gone about engaging with the kernel community is not productive. Unfortunately.

CoC isn't even the issue, he constantly breaks kernel development rules relating to the actual code, then starts arguments with everyone up to and including Linus when he gets called out, and aggressively misses the point every time. Then starts the same argument all over again 6 weeks later.

And, like, if you don't like some rules, then you can have that discussion, but submitting patches you know will be rejected and then re-litigating your dislike of the rules is a waste of everyone's time.

Re: Bcachefs Goes to "Externally Maintained"

#100

Post by ffsm8 »

BoredPositron wrote: post #96
ffsm8 wrote: post #42

Earlier quoted context omitted.

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…

Grounded? Not offensive? https://lore.kernel.org/lkml/CAHk-=wiLE9BkSiq8F-mFW5NOtPzYrt... https://lore.kernel.org/all/citv2v6f33hoidq75xd2spaqxf7nl5wb...

The first one is by Linus? And his replies (at least the ones I read) are - to me- less aggressive then the rest of the mails in that chain

The second has one offensive remark:

> Get your head examined. And get the fuck out of here with this shit.

which I thought he admitted was out of line and - said sorry for. Or do I misremember? I admit once again, I'm still completely uninvolved and merely saw it play out on the internet.

Post reply on HN