GNU bug report logs - #45692
[PATCH 0/4] Even Better ZFS Support on Guix

Previous Next

Full log

View this message in rfc822 format

From: raid5atemyhomework <raid5atemyhomework <at> protonmail.com>
To: Maxime Devos <maximedevos <at> telenet.be>
Cc: "45692 <at> debbugs.gnu.org" <45692 <at> debbugs.gnu.org>
Subject: [bug#45692] [PATCH 0/3] Better Support for ZFS on Guix
Date: Sat, 19 Mar 2022 14:24:22 +0000

Hello Maxime,

>     -   That seems rather inconvenient, why not use BTRFS instead which
>         seems quite capable and doesn't have this weird restriction?

BTRFS IS NOT CAPABLE.

Did you notice my pseudonym?  "`raid5` ate my homework".  I used the BTRFS `raid5` mode, once.  It LOST MY DATA.  Never again.  ZFS supports RAIDZ1 and has not lost my data at all yet.  I've replaced ZFS disks on my pool.  No data loss.  It keeps on going on.

A file system that loses data is not a file system.  It is a disaster.


BTRFS is not an acceptable substitute for ZFS.

If ZFS is removed from Guix, I am switching to Ubuntu and keeping my ZFS pool, I am not going to switch to BTRFS just to keep running Guix,  I would *like* to run only fully-free software, especially since I took the trouble of paying a premium for a server that had coreboot, but my data is more important and BTRFS is not an acceptable substitute for ZFS.


The only restriction needed is to prevent binary redistribution.  Yes, I agree it is inconvenient to always have to transfer source code and recompile each time.  But it is a ***lot*** more inconvenient to replace my lost data because BTRFS couldn't cut it despite more than a decade of development.  At least I can re-download the source code for ZFS each time from many trivial sources.  My `/home`, I cannot.  That is a bigger inconvenience.


Thanks
raid5atemyhomework

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.