Re: [gentoo-user] Re: Suggestions for backup scheme?

["J. Roeleveld" <joost@antarean.org>]

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 <joost@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