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 7A0C615815E for ; Mon, 5 Feb 2024 12:49:16 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id C9378E2A77; Mon, 5 Feb 2024 12:49:09 +0000 (UTC) Received: from gw2.antarean.org (gw2.antarean.org [141.105.125.208]) by pigeon.gentoo.org (Postfix) with ESMTP id 280F9E2A6E for ; Mon, 5 Feb 2024 12:49:08 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by gw2.antarean.org (Postfix) with ESMTP id 4TT5mM5YbBz8scJ for ; Mon, 5 Feb 2024 12:49:07 +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 LWAwXccM_-FP for ; Mon, 5 Feb 2024 12:49:07 +0000 (UTC) Received: from mailstore1.adm.antarean.org (localhost [127.0.0.1]) by gw2.antarean.org (Postfix) with ESMTP id 4TT5mM18t1z8sb4 for ; Mon, 5 Feb 2024 12:49:07 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by mailstore1.adm.antarean.org (Postfix) with ESMTP id 4TT5mM0PTpz1b for ; Mon, 5 Feb 2024 12:49:07 +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 zxe8M6vIO8mJ for ; Mon, 5 Feb 2024 12:48:29 +0000 (UTC) Received: from iris.localnet (iris.adm.antarean.org [10.55.16.47]) by mailstore1.adm.antarean.org (Postfix) with ESMTPA id 4TT5lc6nvTz1M for ; Mon, 5 Feb 2024 12:48:28 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=antarean.org; s=default; t=1707137308; bh=IzjdCDMthNIVfHcMqAdsqimHUefRo9NXEvn3zUB+aCY=; h=From:To:Subject:Date:In-Reply-To:References; b=mBwY6E5w3MHR1Qu7puWBh1jw+Fjhs6L3MCTGi5DeNmUPThS+JXIfFCXiBNev8rp37 GplqXEtKewMlGeNkxDhnktL7asbINNkY90cEAnToTcouUO7+BYdEk7pFqoxZlbtZC6 1WD4+61fHHmHyVj5NH7mSLzzcpbg87CQTbG/uVCs= From: "J. Roeleveld" To: gentoo-user@lists.gentoo.org Subject: Re: [gentoo-user] Re: Suggestions for backup scheme? Date: Mon, 05 Feb 2024 13:48:28 +0100 Message-ID: <4562531.LvFx2qVVIh@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-Type: multipart/alternative; boundary="nextPart2332337.ElGaqSPkdT" Content-Transfer-Encoding: 7Bit X-Archives-Salt: 825a8084-8715-4eaf-aa63-1a3a9f809c8a X-Archives-Hash: cebf4db37004f1351ab6b58899f40fe0 This is a multi-part message in MIME format. --nextPart2332337.ElGaqSPkdT Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="UTF-8" On Wednesday, January 31, 2024 2:01:32 PM CET Rich Freeman wrote: > On Wed, Jan 31, 2024 at 6:45=E2=80=AFAM John Covici wrote: > > I know you said you wanted to stay with ext4, but going to zfs reduced > > my backup time on my entire system from several hours to just a few > > minutes because taking a snapshot is so quick and copying to another > > pool is also very quick. >=20 > Honestly, at this point I would not run any storage I cared about on > anything but zfs. There are just so many benefits. >=20 > I'd consider btrfs, but I'd have to dig into whether the reliability > issues have been solved. I was using that for a while, but I found > that even features that were touted as reliable had problems from time > to time. That was years ago, however. On paper I think it is the > better option, but I just need to confirm whether I can trust it. I actually looked into the state of btrfs last week and it's still far from= usable and not even=20 close to what ZFS offers. =46or a good read: https://arstechnica.com/gadgets/2021/09/examining-btrfs-linuxs-perpetually-= half-finished-filesystem/[1] In short: =2D raid5/6/.. are still broken. =2D Missing drive prevent boot unless you tell it to accept a missing drive. =2D Replacing a broken drive requires a lot of steps to make it sane again =2D- Joost =2D------- [1] https://arstechnica.com/gadgets/2021/09/examining-btrfs-linuxs-perpetua= lly-half-finished-filesystem/ --nextPart2332337.ElGaqSPkdT Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="UTF-8"

On Wednesday, January 31, 2024 2:01:32 PM CET Rich Freeman wrote:

>= ; On Wed, Jan 31, 2024 at 6:45=E2=80=AFAM John Covici <covici@ccs.covici= =2Ecom> wrote:

>= ; > I know you said you wanted to stay with ext4, but going to zfs reduc= ed

>= ; > my backup time on my entire system from several hours to just a few<= /p>

>= ; > minutes because taking a snapshot is so quick and copying to another=

>= ; > pool is also very quick.

>= ;

>= ; Honestly, at this point I would not run any storage I cared about on

>= ; anything but zfs.  There are just so many benefits.

>= ;

>= ; I'd consider btrfs, but I'd have to dig into whether the reliability

>= ; issues have been solved. I was using that for a while, but I found

>= ; that even features that were touted as reliable had problems from time

>= ; to time.  That was years ago, however.  On paper I think it is = the

>= ; better option, but I just need to confirm whether I can trust it.


I actually looked into the state of btrfs last week and it's still far f= rom usable and not even close to what ZFS offers.


For a good read:

https://arstechnica.com/gadgets/2021/09/= examining-btrfs-linuxs-perpetually-half-finished-filesystem/


In short:

- r= aid5/6/.. are still broken.

- M= issing drive prevent boot unless you tell it to accept a missing drive.

- R= eplacing a broken drive requires a lot of steps to make it sane again


--

Joo= st

--nextPart2332337.ElGaqSPkdT--