4 ms·
I big future (unless ZFS licensing incompatibility is solved)
by opengears 3y ago
I big future (unless ZFS licensing incompatibility is solved)
- maxloh 3y agoMaybe replace Oracle-owned code with a clean room implementation?
- DaSHacka 3y agoWould you not basically be starting over at that point, though?
- arp242 3y agoThey did that. It's called "btrfs". A stable clean-room ZFS with on-disk compatibility would be a huge task. How long did stable NTFS write capability take? And NTFS is a much simpler filesystem. It would also be a huge waste of time given that btrfs and bcachefs exist, and that ZFS is fine to use license-wise – it's just distribution that's a tad awkward (but not overly so).
- rascul 3y agoInteresting to note here that btrfs came from Oracle.
- tadfisher 3y ago"Chris Mason is the founding developer of btrfs, which he began working on in 2007 while working at Oracle. This leads many people to believe that btrfs is an Oracle project—it is not. The project belonged to Mason, not to his employer, and it remains a community project unencumbered by corporate ownership to this day." https://arstechnica.com/gadgets/2021/09/examining-btrfs-linuxs-perpetually-half-finished-filesystem/ https://arstechnica.com/gadgets/2021/09/examining-btrfs-linu...
- chungy 3y agoThat's countered by btrfs's source code always beginning with "Copyright (C) 2007 Oracle." Maybe it was Mason's pet project within the company, but there is no ambiguity that Oracle owns it. It is an Oracle project.
- arp242 3y agoA copyright line doesn't make it an "Oracle project". That implies a high level of control/involvement in the project.
- chungy 3y agoIt shows belonging, at the very least. The quote from Jim Salter was "The project belonged to Mason, not to his employer" (emphasis added). The copyright line demonstrably and incontestably refutes this claim. btrfs belongs to Oracle.
- yjftsjthsd-h 3y agoI don't think that would work; all of the changes since the fork are also CDDL and they aren't owned by any one entity/person. (IANAL)
- maxloh 3y agoGPL only forbids ZFS to be distributed alongside Linux, it doesn't prevent users from installing it manually. (IANAL)
- deleted 3y ago[deleted]
- mustache_kimono 3y ago> GPL only forbids ZFS to be distributed alongside Linux But does it even do that? You might be surprised when/if you read a little more widely. Position of OpenZFS project[0] is which I find persuasive (my emphasis added): In the case of the Linux Kernel, this prevents us from distributing OpenZFS as part of the Linux Kernel binary. *However, there is nothing in either license that prevents distributing it in the form of a binary module* or in the form of source code. [0]: https://openzfs.github.io/openzfs-docs/License.html https://openzfs.github.io/openzfs-docs/License.html You might see also: [1]: https://www.networkworld.com/article/836039/smb-encouraging-closed-source-modules-part-1-copyright-and-software.html https://www.networkworld.com/article/836039/smb-encouraging-... [2]: https://law.resource.org/pub/us/case/reporter/F2/977/977.F2d.1510.92-15655.html https://law.resource.org/pub/us/case/reporter/F2/977/977.F2d...
- lmz 3y agoIt doesn't matter what the project thinks as long as there is code owned by Oracle in the FS.
- mustache_kimono 3y ago> It doesn't matter what the project thinks as long as there is code owned by Oracle in the FS. Might we agree then that the only thing that really matters is the law? And we should ignore other opinions coughlike from the FSF/the SFCcough which don't make reference to the law? Or which ignore long held copyright law principles, like fair use? Please take a look at the case law. The so far theoretical claim of OpenZFS/Linux incompatibility is especially weak re: a binary kernel module.
- throw0101d 3y agoWhy would Btrfs have a big(ger) future than Bcachefs when the latter seems to have the same functionality and less 'historical baggage'†? I remember when Btrfs was initially released (I was doing Solaris sysadmining, and it was billed as "ZFS for Linux"), and yet here we are all these years later and it still seems to be 'meh'. † E.g., RAID5+ that's less likely to eat data: * https://btrfs.readthedocs.io/en/latest/btrfs-man5.html#raid56-status-and-recommended-practices https://btrfs.readthedocs.io/en/latest/btrfs-man5.html#raid5... * https://bcachefs.org/ErasureCoding/ https://bcachefs.org/ErasureCoding/ / https://github.com/koverstreet/bcachefs/issues/657 https://github.com/koverstreet/bcachefs/issues/657
- bhaney 3y agoBy the time future-bcachefs has feature parity with present-btrfs, who knows what more will be in future-btrfs? For your specific example, bcachefs's erasure coding is very experimental and currently pretty much unusable, while btrfs is actively working towards fixing the raid56 write hole with the recent addition of the raid-stripe-tree. By the time bcachefs has a trustworthy parity profile, btrfs's may be just as good.
- curt15 3y agoBcachefs has not advertised erasure coding as production ready only to renege on that claim later. So nobody has been unwittingly burned yet.
- throw0101d 3y ago> For your specific example My specific example says that the bcachefs are "actively working towards fixing the raid56 write hole" as well—or rather, their way of doing things doesn't have one in the first place.
- bhaney 3y ago> bcachefs are "actively working towards fixing the raid56 write hole" as well Yep, that's my point. Neither btrfs nor bcachefs have a write-hole-less parity raid profile implementation yet, and both are working towards one. We don't know if one will be finished and battle tested significantly before the other, or if one will prove to be more performant or reliable. Just have to wait and see.