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

371–380 of 400 posts

Re: Bcachefs Goes to "Externally Maintained"

#371

Post by chao- »

p_l wrote: post #340
tzs wrote: post #335

Earlier quoted context omitted.

> Additionally, GPLv2 does not prevent shipping ZFS combined with GPL code, because CDDL code is not derivative work of GPLv2 code . So it's legal to ship. The CDDL code is not a derivative work of GPLv2 code, but the combined work as a whole is a derivative work of GPLv2 code (assuming by "combined" we are talking about shipping an executable made by compiling and linking GPLv2 and CDDL code together). Shipping that…

The derivative portions of the ZFS driver are dual-licensed GPLv2/CDDL. The CDDL-only parts of the driver are portable between OSes, removing the "derivative code" argument (similar argumentation goes back to introduction of AFS driver for Linux, IIRC). Remember, GPLv2 does not talk about linking. Derivativeness is decided by source code, among other things whether or not the non-GPL code can't exist/operate without…

I appreciate the detailed explanations. I understand some of the basics, and this has given me some more routes to read up on and learn.

Re: Bcachefs Goes to "Externally Maintained"

#372

Post by pabs3 »

cyphar wrote: post #356
p_l wrote: post #354

Earlier quoted context omitted.

0) Assuming Oracle actually retains the stewardship of license: 1) Making CDDL compatible with GPLv2 puts everyone using CDDL code at mercy of Oracle patents 2) OpenZFS is actually not required to upgrade, and the team has indicated they won't. So you end up with a fork you need to carry yourself. Might even force OpenZFS to ensure that it's specifically 1.0. Ultimately it means Oracle can't do much with this.

0) They do. 1) They could just adapt MPL-2.0, which provides GPLv2+ compatibility while still providing the same patent grants. 2) The upgrade is chosen by downstream users. The OpenZFS project could ask individual contributiors to choose to license their future contributions differently but that will only affect future versions and isn't a single decision made by the project leads. I don't know in what context that…

IIRC from LWN discussions, some of the newer OpenZFS code is now CDDL-1-only and could not be upgraded to CDDL-2.0 without explicit agreement from the owners of the new code.

Re: Bcachefs Goes to "Externally Maintained"

#373

Post by philipallstar »

jeltz wrote: post #249
philipallstar wrote: post #82

Earlier quoted context omitted.

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

I agree that is a problem, but the main thing the eye-rolling posts seem to be about is CoC stuff, real or imaginary.

Example of eye-rolling post, above:

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

And there's an email thread linked somewhere here where a CoC member repeatedly replies to Kent's emails with demands for a formal apology. All of this soft, subtle stuff adds up to an impression in people's heads, even though the main output of these projects should be highly complex software, and not bike-shedding email mediation.

Re: Bcachefs Goes to "Externally Maintained"

#374

Post by [deleted] »

koverstreet wrote: post #159
TheAceOfHearts wrote: post #147

Earlier quoted context omitted.

> But there's a ton of room for improvement beyond what ZFS did. Say more? I can't say I've really thought that much about filesystems and I'm curious in what direction you think they could be taken if time and budget weren't an issue.

that would be bcachefs :) It's an entirely clean slate design, and I spent years taking my time on the core planning out the design; it's as close to perfect as I can make it. The only things I can think of that I would change or add given unlimited time and budget: - It should be written in Rust, and even better a Rust + dependent types (which I suspect could be done with proc macros) for formal verification. And ca…

[deleted]

Re: Bcachefs Goes to "Externally Maintained"

#375

Post by ajross »

yjftsjthsd-h wrote: post #91
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.

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

So... there's a reason you had to cite a throwaway comment on a distro wiki and not documentation. Needless to say journaling metadata (something done in some form by every filesystem you will ever use!) does not, in fact, "halve the write speed".

Re: Bcachefs Goes to "Externally Maintained"

#376

Post by ajross »

koverstreet wrote: post #102
ajross wrote: post #95

Earlier quoted context omitted.

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…

1 - you absolutely can and should walk reverse mappings in the filesystem so that from a corrupt block you can tell the user which file was corrupted. In the future bcachefs will be rolling out auxiliary dirent indices for a variety of purposes, and one of those will be to give you a list of files that have had errors detected by e.g. scrub (we already generally tell you the affected filename in error messages) 2 - N…

> 2 - No, metadata robustness absolutely varies across filesystems.

That's misunderstanding the subthread. The upthread point was about metadata atomicity in snapshots, not hardware corruption recovery. A filesystem like ZFS can make sure the journal is checkpointed atomically with the CoW snapshot moment, where dm obviously can't. And I pointed out this wasn't actually helpful because this is a problem that has to be solved above the filesystem, in databases and apps, because it's isomorphic to power loss (something that the filesystem can't prevent).

Re: Bcachefs Goes to "Externally Maintained"

#377

Post by nh2 »

ajross wrote: post #376
koverstreet wrote: post #102

Earlier quoted context omitted.

1 - you absolutely can and should walk reverse mappings in the filesystem so that from a corrupt block you can tell the user which file was corrupted. In the future bcachefs will be rolling out auxiliary dirent indices for a variety of purposes, and one of those will be to give you a list of files that have had errors detected by e.g. scrub (we already generally tell you the affected filename in error messages) 2 - N…

> 2 - No, metadata robustness absolutely varies across filesystems. That's misunderstanding the subthread. The upthread point was about metadata atomicity in snapshots, not hardware corruption recovery. A filesystem like ZFS can make sure the journal is checkpointed atomically with the CoW snapshot moment, where dm obviously can't. And I pointed out this wasn't actually helpful because this is a problem that has to b…

I believe it is helpful because you can stop an app (such as a DB), FS-snapshot, and then e.g. rsync the snapshot or use any other file based backup tool, and this snapshot is fast and will be correct.

Doing the same with a block device snapshot is not so easy.

Re: Bcachefs Goes to "Externally Maintained"

#378

Post by yjftsjthsd-h »

ajross wrote: post #375
yjftsjthsd-h wrote: post #91

Earlier quoted context omitted.

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

So... there's a reason you had to cite a throwaway comment on a distro wiki and not documentation. Needless to say journaling metadata (something done in some form by every filesystem you will ever use!) does not, in fact, "halve the write speed".

> So... there's a reason you had to cite a throwaway comment on a distro wiki and not documentation.

No, I read the official kernel docs too; the Arch wiki just happened happened to be a quicker way to describe it.

From https://docs.kernel.org/admin-guide/device-mapper/dm-integri... -

> The dm-integrity target can also be used as a standalone target, in this mode it calculates and verifies the integrity tag internally. In this mode, the dm-integrity target can be used to detect silent data corruption on the disk or in the I/O path.

> There’s an alternate mode of operation where dm-integrity uses a bitmap instead of a journal. If a bit in the bitmap is 1, the corresponding region’s data and integrity tags are not synchronized - if the machine crashes, the unsynchronized regions will be recalculated. The bitmap mode is faster than the journal mode, because we don’t have to write the data twice, but it is also less reliable, because if data corruption happens when the machine crashes, it may not be detected.

This is more clearly presented lower down in the list of modes, in which most options describe how they don't actually protect against crashes, except for journal mode:

> J - journaled writes

> data and integrity tags are written to the journal and atomicity is guaranteed. In case of crash, either both data and tag or none of them are written. The journaled mode degrades write throughput twice because the data have to be written twice.

On further reflection, I grant that that might only be talking about the integrity metadata, in which case we just don't know about the impact to data writes and it would be useful to go benchmark to see what the hit is in practice.

EDIT: So I went looking to see if anyone had done that benchmarking and found https://github.com/t13a/dm-integrity-benchmarks which seems to show that actually yes dm-integrity is that bad on data writes. Of course, its possible saving grace is that everything else with the same features also had a performance hit. I also found https://www.reddit.com/r/linuxadmin/comments/1crtggd/why_dmi... talking about it.

Re: Bcachefs Goes to "Externally Maintained"

#379

Post by ajross »

nh2 wrote: post #377
ajross wrote: post #376

Earlier quoted context omitted.

> 2 - No, metadata robustness absolutely varies across filesystems. That's misunderstanding the subthread. The upthread point was about metadata atomicity in snapshots, not hardware corruption recovery. A filesystem like ZFS can make sure the journal is checkpointed atomically with the CoW snapshot moment, where dm obviously can't. And I pointed out this wasn't actually helpful because this is a problem that has to b…

I believe it is helpful because you can stop an app (such as a DB), FS-snapshot, and then e.g. rsync the snapshot or use any other file based backup tool, and this snapshot is fast and will be correct. Doing the same with a block device snapshot is not so easy.

Again, if your system is "incorrect" having been stopped and snapshotted like that, it is also unsafe vs. power loss, something ZFS cannot save you from. Power loss events are vastly more common than poorly checkpointed database[1] events.

[1] FWIW: every database worth being called a "database" has some level of robust journaling with checkpoints internally. I honestly don't know what software you're talking about specifically except to say that you're likely using it wrong.

Re: Bcachefs Goes to "Externally Maintained"

#380

Post by ajross »

yjftsjthsd-h wrote: post #378
ajross wrote: post #375

Earlier quoted context omitted.

So... there's a reason you had to cite a throwaway comment on a distro wiki and not documentation. Needless to say journaling metadata (something done in some form by every filesystem you will ever use!) does not, in fact, "halve the write speed".

> So... there's a reason you had to cite a throwaway comment on a distro wiki and not documentation. No, I read the official kernel docs too; the Arch wiki just happened happened to be a quicker way to describe it. From https://docs.kernel.org/admin-guide/device-mapper/dm-integri... - > The dm-integrity target can also be used as a standalone target, in this mode it calculates and verifies the integrity tag internall…

FWIW, the github link you show clearly shows the ext4-on-dm stack to be FASTER than ZFS!

It only falls behind, and very signficantly so, on the 1M sequential write test, exactly the situation where you'd expect there to be the least delta between systems! I'm going to bet anything that's a misconfigured RAID.

Frankly looking at that from a "will this work best for my general purpose filesystem used mostly to handle giant software builds and Zephyr test suites" it seems like a no brainer to pick dm, especially so given the simplicity argument.

Post reply on HN