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

331–340 of 400 posts

Re: Bcachefs Goes to "Externally Maintained"

#331

Post by magicalhippo »

koverstreet wrote: post #320
magicalhippo wrote: post #308

Earlier quoted context omitted.

> What happens on ZFS if you lose all your alloc info? According to this[1] old issue, it hasn't happened frequently enough to prioritize implementing a rebuild option, however one should be able to import the pool read-only and zfs send it to a different pool. As far as I can tell that's status quo. I agree it is something that should be implemented at some point. That said, certain other spacemap errors might be re…

I take a harder line on repair than the ZFS devs, then :) If I see an issue that causes a filesystem to become unavailable _once_, I'll write the repair code. Experience has taught me that there's a good chance I'll be glad I did, and I like the peace of mind that I get from that. And it hasn't been that bad to keep up on, thanks to lucky design decisions. Since bcachefs started out as bcache, with no persistent allo…

As I said I do think ZFS is great, but there are aspects where it's quite noticeable it was born in an enterprise setting. That sending, recreating and restoring the pool is a sufficient disaster recovery plan to not warrant significant development is one of those aspects.

As I mentioned in the other subthread, I do think your commitment to help your users is very commendable.

Re: Bcachefs Goes to "Externally Maintained"

#332

Post by mustache_kimono »

kstrauser wrote: post #30
mustache_kimono wrote: post #15

Earlier quoted context omitted.

> Damn. I was enjoying not having to deal with the fun of ZFS and DKMS, but it seems like now bcachefs will be in the same boat, either dealing with DKMS and occasional breakage or sticking with the kernel version that slowly gets more and more out of date. Your distro could very easily include bcachefs if it wishes? Although I think the ZFS + Linux situation is mostly Linux religiosity gone wild, that very particula…

> Although I think the ZFS + Linux situation is mostly Linux religiosity gone wild I can think of non-religious reasons to want to avoid legal fights with Oracle.

>> I can think of non-religious reasons to want to avoid legal fights with Oracle.

Oh, certainly, but that's really not the problem posed right now. Oracle's own lawyers have said they see no problem with the combination, and Ubuntu has shipped the Linux + ZFS combination for years without a lawsuit.[0][1]

In the 1990s, Microsoft/SCO, like you, would also fear monger about open source and lawsuits, and we in the OSS community mostly called this "FUD" (fear, uncertainty, and doubt). Whereas now, almost 10 years into this experiment, we know more about the ZFS + Linux combination, and what Oracle will do about it, than most other open questions in OSS, and the answer is that some in OSS community have chosen to instead participate in the same kind of FUD because of a very online, very uninformed internecine licensing debate.

[0]: https://www.youtube.com/watch?v=PFMPjt_RgXA&t=2260s [1]: https://ubuntu.com/blog/zfs-is-the-fs-for-containers-in-ubun...

Re: Bcachefs Goes to "Externally Maintained"

#333

Post by highpost »

tuna74 wrote: post #207
chao- wrote: post #204

Earlier quoted context omitted.

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.

Ubuntu ships OpenZFS as a separate prebuilt kernel module for ZFS (zfs-dkms). Interestingly, they also have ZFS support in GRUB to support booting from ZFS:

  * read-only and minimal
  * fully aware of different Linux boot environments
  * GPLv3 license compatible, clean-room implementation by the OpenSolaris/Illumos team. The implementation predates Ubuntu’s interest.

Re: Bcachefs Goes to "Externally Maintained"

#334

Post by shmerl »

rob_c wrote: post #285
masklinn wrote: post #179

Earlier quoted context omitted.

It won’t. Kent is in this very post (as well as TFA) showing that he’s not learned anything

Shame, at the very least I was hoping this would lead to approaching someone to work as a go between. (I find it difficult to believe nobody tried to step up to that position either)

Yeah, I don't really get why Kent wouldn't find people to handle upstreaming process that will satisfy Linus if he can't handle it himself. It would solve the problem and avoid all this collaboration friction.

If there is a need for out of tree emergency patches (until they get merged), it can always be communicated somewhere.

Re: Bcachefs Goes to "Externally Maintained"

#335

Post by tzs »

p_l wrote: post #323
chao- wrote: post #254

Earlier quoted context omitted.

I am aware of that. I did a bad job phrasing my post, and it came off sounding more confident than I actually intended. I have two questions: (1) What are the expected consequences of a violation? (2) Why haven't any consequences occurred yet? My understanding is that Canonical is shipping ZFS with Ubuntu. Or do I misunderstand? Has Canonical not actually done the big, bad thing of distributing the Linux kernel with…

Oracle has no standing. 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. It could be problematic to upstream, because kernel development would demand streamlining to the point that the code would be derivative . Additionally, two or three kernel contributors decided that the long standing consensus on derivative w…

> 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 work does require permission from both the GPLv2 code copyright owners and the CDDL code copyright owners unless the code from on or the other can be justified under fair use or if it was a part of the GPLv2 or CDDL code that is not subject to copyright.

What Canonical does is ship ZFS as a kernel module. That contains minimal GPLv2 code from the kernel that should be justifiable as fair use (which seems like a decent bet after the Oracle vs Google case).

Re: Bcachefs Goes to "Externally Maintained"

#336

Post by koverstreet »

magicalhippo wrote: post #330
koverstreet wrote: post #324

Earlier quoted context omitted.

All I need to support bcachefs is for the same rules to apply as they are to every other subsystem.

From what I have read and recall, the same rules do apply. Rather, the disagreement seems to be over what constitutes a feature and what constitutes a bugfix. As I recall, your view is that the repair code is part of the bugfix. However Linus deems it a feature, and thus applied the "no new features outside the merge window" rule. I think Linus is correct here and you are wrong. New code made to repair flaws that pre…

New features go in during RCs all the time.

The hard rule you're thinking of doesn't exist, it's all risk vs. reward.

Re: Bcachefs Goes to "Externally Maintained"

#337

Post by koverstreet »

magicalhippo wrote: post #331
koverstreet wrote: post #320

Earlier quoted context omitted.

I take a harder line on repair than the ZFS devs, then :) If I see an issue that causes a filesystem to become unavailable _once_, I'll write the repair code. Experience has taught me that there's a good chance I'll be glad I did, and I like the peace of mind that I get from that. And it hasn't been that bad to keep up on, thanks to lucky design decisions. Since bcachefs started out as bcache, with no persistent allo…

As I said I do think ZFS is great, but there are aspects where it's quite noticeable it was born in an enterprise setting. That sending, recreating and restoring the pool is a sufficient disaster recovery plan to not warrant significant development is one of those aspects. As I mentioned in the other subthread, I do think your commitment to help your users is very commendable.

Oh, I'm not trying to diss ZFS at all. You and I are in complete agreement, and ZFS makes complete sense in multi device setups with real redundancy and non garbage hardware - which is what it was designed for, after all.

Just trying to give honest assessments and comparisons.

Re: Bcachefs Goes to "Externally Maintained"

#338

Post by koverstreet »

trueismywork wrote: post #314
koverstreet wrote: post #299

Earlier quoted context omitted.

No, really. People aren't losing data on bcachefs. We still have minor hiccups that do affect usability, and I put a lot of effort into educating users about where we're at and what to expect. In the past I've often told people who wanted to migrate off of btrfs "check back in six months", but I'm not now because 6.16 is looking amazingly solid; all the data I have says that your data really is safer on bcachefs than…

You're arguing in circles. Either bcachefs is experimental and hence needs a lot of changes and tools to make sure that users dont lose data and hence the fixes are not critical/users can use a custom branch. Or it is stable and the only thing users need is actual big fixes. Not new tools in an RC3. Don't compare bcachefs with btrfs for stability. Compare it with ext4. (And dont care anecdotal data, compare the proce…

So, are we agreeing that btrfs isn't fit for purpose, then?

Re: Bcachefs Goes to "Externally Maintained"

#339

Post by nylonstrung »

koverstreet wrote: post #286
mort96 wrote: post #255

Earlier quoted context omitted.

You get a ton of comments like this because it's true. There are real problems in the kernel, I've seen how hostile it can be to people who are just trying to do the right thing and upstream their changes etc. But your case isn't that. Your behavior would get you in trouble at any job where you have to follow rules set by other people. Your refusal to treat your part of the kernel as anything other than your personal…

That's because it is my project, and my responsibility. I can't be bowing to the demands of any one person; I have to balance the wants and needs of everyone and prioritize shipping something that works above all else. Repeatedly we've seen that those priorities are not shared, unfortunately. Arguments are just as heated as they ever were, but now instead of arguing over the actual issues - does this work, are we doi…

I really want bcachefs to succeed.

Please just swallow your pride like all the other maintainers.

This is so self-defeating and it's disappointing the drama has overshadowed the project

Re: Bcachefs Goes to "Externally Maintained"

#340

Post by p_l »

tzs wrote: post #335
p_l wrote: post #323

Earlier quoted context omitted.

Oracle has no standing. 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. It could be problematic to upstream, because kernel development would demand streamlining to the point that the code would be derivative . Additionally, two or three kernel contributors decided that the long standing consensus on derivative w…

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

Post reply on HN