From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by finch.gentoo.org (Postfix) with ESMTPS id 43DB015815E for ; Tue, 6 Feb 2024 13:14:59 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id A79B7E29E2; Tue, 6 Feb 2024 13:14:52 +0000 (UTC) Received: from gw2.antarean.org (gw2.antarean.org [141.105.125.208]) by pigeon.gentoo.org (Postfix) with ESMTP id 33551E29D0 for ; Tue, 6 Feb 2024 13:14:51 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by gw2.antarean.org (Postfix) with ESMTP id 4TTkHb2p6rz8scJ for ; Tue, 6 Feb 2024 13:14:51 +0000 (UTC) X-Virus-Scanned: amavisd-new at antarean.org Received: from gw2.antarean.org ([127.0.0.1]) by localhost (gw2.antarean.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b8gCfMONUCHJ for ; Tue, 6 Feb 2024 13:14:50 +0000 (UTC) Received: from mailstore1.adm.antarean.org (localhost [127.0.0.1]) by gw2.antarean.org (Postfix) with ESMTP id 4TTkHZ4z9lz8sb4 for ; Tue, 6 Feb 2024 13:14:50 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by mailstore1.adm.antarean.org (Postfix) with ESMTP id 4TTkDx71GKz1M for ; Tue, 6 Feb 2024 13:12:33 +0000 (UTC) X-Virus-Scanned: amavisd-new at antarean.org Received: from mailstore1.adm.antarean.org ([127.0.0.1]) by localhost (mailstore1.adm.antarean.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b6ksodzzkVlt for ; Tue, 6 Feb 2024 13:12:13 +0000 (UTC) Received: from iris.localnet (iris.adm.antarean.org [10.55.16.47]) by mailstore1.adm.antarean.org (Postfix) with ESMTPA id 4TTkDY2Q37z15 for ; Tue, 6 Feb 2024 13:12:13 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=antarean.org; s=default; t=1707225133; bh=/2D5kWAEPZ05fsJw1VGInpGncXurPMgj7IFkJDHxPOE=; h=From:To:Subject:Date:In-Reply-To:References; b=Da2gBgcR25wUW7GUTc2rKCo3xqyBJ9hZK8PLOMmC6YLgvqsf2tWX/gfEfyKKbHF0w 06VCqHDPU4IahISP+HnXCm66ucyrQxzIzciI1GNeqp7AUKiOa9ynsADV/tKkgkTypC Iwinpk7RKAcb5FDBgqzNfUcUD7Eq4wVCaSJq8vYw= From: "J. Roeleveld" To: gentoo-user@lists.gentoo.org Subject: Re: [gentoo-user] Re: Suggestions for backup scheme? Date: Tue, 06 Feb 2024 14:12:13 +0100 Message-ID: <4559170.LvFx2qVVIh@iris> In-Reply-To: References: <13464302.uLZWGnKmhe@iris> Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-user@lists.gentoo.org Reply-to: gentoo-user@lists.gentoo.org X-Auto-Response-Suppress: DR, RN, NRN, OOF, AutoReply MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="UTF-8" X-Archives-Salt: 1cf9060c-304d-41cd-a5cb-b3c7b8c2e592 X-Archives-Hash: e36f1139d66e6eec6074bad1c8a9eba2 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 btr= fs.=20 I was actually hoping that the biggest issues had been resolved by now. > On Mon, Feb 5, 2024 at 7:55=E2=80=AFAM J. Roeleveld = 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. > >=20 > > 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 behi= nd > > the GPL-wall if you simply remove that wall from your own kernel. > > (Which is advisable as it will improve performance) >=20 > 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/N= AS=20 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. >=20 > 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. > >=20 > > After all this time, I have given up on waiting for btrfs. As mentioned= in > > my other reply, it's still nowhere near reliable. >=20 > 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=20 private projects that I could publish. But before I do that, I'd have to=20 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=3D*grub*2 ... > > - Refer to /usr/share/zfs/compatibility.d/*grub*2 for list of features. >=20 > 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. >=20 > 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 i= s=20 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 =2D- Joost