On Monday, February 5, 2024 2:35:12 PM CET Rich Freeman wrote: > First, thanks for the Ars link in the other email. I'll give that a read.
You're welcome. I found that when I was looking for the latest state of btrfs. I was actually hoping that the biggest issues had been resolved by now. > On Mon, Feb 5, 2024 at 7:55 AM J. Roeleveld <jo...@antarean.org> wrote: > > On Wednesday, January 31, 2024 6:56:47 PM CET Rich Freeman wrote: > > > The main barrier is that its license isn't GPL-compatible. It is > > > FOSS, but the license was basically designed to keep it from being > > > incorporated into the mainline kernel. > > > > Which isn't as much of an issue as it sounds. You can still add it into > > the > > initramfs and can easily load the module. > > And the code still works with the functions the kernel devs pushed behind > > the GPL-wall if you simply remove that wall from your own kernel. > > (Which is advisable as it will improve performance) > > So, that's great for random individuals, but companies are going to be > hesitant to do that, especially for anything they redistribute. This > is part of why it isn't mainstream. Not for Linux. *BSD has no such issues and that is why the mainstream SAN/NAS distributions are based on *BSD. (replace '*' with your preferred flavour) > A big part of the reason that Linux is mainstream is that it doesn't > have any legal/license encumbrances. If you have 100 instances of > something and want to have 200 instances, you just turn a dial or add > hardware. There isn't anybody you need to get permission from or pay. > <snipped> > The result is that the murky legal situation makes ZFS unattractive. > If I were publishing some large commercial software package, I'd > personally be hesitant to embrace ZFS on Linux in it for that reason, > even though I use it all the time personally. Proxmox has ZFS native and afaik, it is using Linux? > > > The odd thing is that right now Oracle controls both ZFS and btrfs, > > > with the latter doing mostly the same thing and being GPL-compatible, > > > but it hasn't tended to be as stable. So we're in a really long > > > transitional period to btrfs becoming as reliable. > > > > After all this time, I have given up on waiting for btrfs. As mentioned in > > my other reply, it's still nowhere near reliable. > > Clearly Oracle likes this state of affairs. Either that, or they are > encumbered in some way from just GPLing the ZFS code. Since they on > paper own the code for both projects it seems crazy to me that this > situation persists. GPL is not necessarily the best license for releasing code. I've got some private projects that I could publish. But before I do that, I'd have to decide on a License. I would prefer something other than GPL. > > To make this easier, there is a compatiblity option when creating a new > > zpool. It's also listed in the zfs-kmod ebuild: > > - zpool create -o compatibility=*grub*2 ... > > - Refer to /usr/share/zfs/compatibility.d/*grub*2 for list of features. > > Oh, that is VERY helpful. I've found random many-years-old webpages > with the appropriate instructions, but something that is part of the > maintained project is much more useful. > > Granted, I think the bottom line is that boot probably shouldn't be on > the same filesystem as large volumes of data, as these feature > restrictions are going to be cumbersome. I'm guessing you can't > shrink vdevs, for example. I actually have the kernel and initramfs on a EFI boot partition and that is enough to get the zpool mounted for use. There is also "ZFSBootMenu" which, afaik, doesn't need this: https://docs.zfsbootmenu.org/en/latest/index.html -- Joost
