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) server-digest SHA256) (No client certificate requested) by finch.gentoo.org (Postfix) with ESMTPS id B8B8F15815E for ; Mon, 5 Feb 2024 12:58:44 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 83AF9E2A77; Mon, 5 Feb 2024 12:58:40 +0000 (UTC) Received: from gw2.antarean.org (gw2.antarean.org [141.105.125.208]) by pigeon.gentoo.org (Postfix) with ESMTP id E78E1E2A6E for ; Mon, 5 Feb 2024 12:58:39 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by gw2.antarean.org (Postfix) with ESMTP id 4TT5zM2B1dz8scJ for ; Mon, 5 Feb 2024 12:58:39 +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 4iGAQB0ESt9n for ; Mon, 5 Feb 2024 12:58:38 +0000 (UTC) Received: from mailstore1.adm.antarean.org (localhost [127.0.0.1]) by gw2.antarean.org (Postfix) with ESMTP id 4TT5zL67gcz8sb4 for ; Mon, 5 Feb 2024 12:58:38 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by mailstore1.adm.antarean.org (Postfix) with ESMTP id 4TT5wl3PCJz1H for ; Mon, 5 Feb 2024 12:56:23 +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 ShEEQe1phWB2 for ; Mon, 5 Feb 2024 12:55:38 +0000 (UTC) Received: from iris.localnet (iris.adm.antarean.org [10.55.16.47]) by mailstore1.adm.antarean.org (Postfix) with ESMTPA id 4TT5vs6KDBz1R for ; Mon, 5 Feb 2024 12:55:37 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=antarean.org; s=default; t=1707137737; bh=GfHr6GJ9kXBKqJwXR/cdHxCx1RKPRFhmuvQN3gLBuSk=; h=From:To:Subject:Date:In-Reply-To:References; b=BHfL+NgsHgerUZknGtAZOxjqyuDXBXaN5DZq5wZrOVPqjMPrf5JLIbaMeREXFXLpx DJKSbfOGBIIF3jdMamuo19eBlIWPihtrHNgKZ+/kxQEzvMx+Qphw8wmgooy/EG0OOE jsvltZXqseV01mFNbVeCqQAwPih/VZ+6+PYQpMYA= From: "J. Roeleveld" To: gentoo-user@lists.gentoo.org Subject: Re: [gentoo-user] Re: Suggestions for backup scheme? Date: Mon, 05 Feb 2024 13:55:37 +0100 Message-ID: <13464302.uLZWGnKmhe@iris> In-Reply-To: References: 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: ba1f69dd-b241-47f4-b0a6-9147b2ad447a X-Archives-Hash: f4cbed3d2629f834968deed3261150d6 On Wednesday, January 31, 2024 6:56:47 PM CET Rich Freeman wrote: > On Wed, Jan 31, 2024 at 12:40=E2=80=AFPM Thelma = wrote: > > If zfs file system is superior to ext4 and it seems to it is. > > Why hasn't it been adopted more widely in Linux? >=20 > 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= =20 initramfs and can easily load the module. And the code still works with the functions the kernel devs pushed behind t= he=20 GPL-wall if you simply remove that wall from your own kernel. (Which is advisable as it will improve performance) > 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=20 other reply, it's still nowhere near reliable. > ZFS also cannot be shrunk as easily. I think that is something that > has been improved more recently, but I'm not certain of the state of > it. Also, bootloaders like grub aren't 100% compatible with all of > its later features, and it isn't even clear in the docs which ones are > and aren't supported. So it doesn't hurt to keep /boot off of zfs. To make this easier, there is a compatiblity option when creating a new zpo= ol.=20 It's also listed in the zfs-kmod ebuild: =2D zpool create -o compatibility=3D*grub*2 ... =2D Refer to /usr/share/zfs/compatibility.d/*grub*2 for list of features. =2D- Joost