On Fri, Feb 24, 2023 at 09:31:22AM -0500, John Mellor wrote:
Ok, I'm anticipating a firestorm of BS responses on this, but
here goes
anyway.
We've now had BTRFS as the default filesystem for some time in Fedora.
However, there has been almost nothing done to take advantage of its
capabilities. This leads to some obvious questions about future work:
1) When are we going to see removal of the EXT2 /boot partition? It is no
longer required, as the boot process has been able to use BTRFS for years
now.
The entire boot story is undergoing work now. The historical reason for
/boot is encrypted installs. You need a unencryped thing to have the
kernel/initramfs so it can boot up and unlock the encrypted drive.
2) When are we going to see timeshifting tools built into the
desktop, ala
Solaris? That's incredibly useful for developers.
No idea there. When someone writes something I suppose.
3) The existing Windows-like update mechanism is undesirable. It solves a
non-existent problem on filesystems with inodes. Like all Unix-like systems,
even Ubuntu does not require this. The ability to snapshot means that the
weird reasoning that requires 2 reboots to install virtually all update
packages is no longer required under any circumstances. When is the
software update mechanism getting a fundamental redesign?
I guess you are talking about offline updates here?
It's the only way to do things in a completely reliable way. Updates are
applied in a minimal boot target and you are 100% sure everything is
restarted.
If you really don't like it you can choose to just apply updates with
dnf directly/live. Of course you will then be responsible for restarting
everything that needs to be and deal with issues with running
applications that have issues with being updated in this manner.
offline updates are a full solution to the problem, and much better for
most users.
4) When is a standard backup mechanism that takes advantage of
snapshotting
going to be in the distro? The published backup packages do not seem to be
aware of the better capabilities available in BTRFS. Wrapping a few CLI
tools in a GUI seems like it should be obvious, maybe 200 lines of
shellscript or less.
There's a number already available.
to name two:
Name : btrfs-sxbackup
Summary : Incremental btrfs snapshot backups with push/pull support via SSH
URL :
https://github.com/masc3d/btrfs-sxbackup
License : GPLv2+
Description : Btrfs snapshot backup utility with push/pull support via SSH, retention,
Email
: notifications, compression of transferred data, and syslog logging.
Name : btrbk
Summary : Tool for creating snapshots and remote backups of btrfs sub-volumes
URL :
https://digint.ch/btrbk/
License : GPLv3+
Description : Backup tool for btrfs sub-volumes, using a configuration file, allows
: creation of backups from multiple sources to multiple destinations,
: with ssh and flexible retention policy support (hourly, daily,
: weekly, monthly)
5) If you encrypt your filesystems, the BTRFS built-in encryption
mechanism
is not used. Why not? LUKS is still in use, even though that is more
complicated and slower. I note the possible ability to encrypt being added
if F38, but it seems like baby steps when a general solution is already in
the code.
I've not followed it closely, but my understanding is that native btrfs
encryption is still not landed in the linux kernel. You have to use
dm-crypt currently, which uses LUKS.
6) Compression is not the default. Why not? SSDs are 10x slower and
disks
are 100x slower than the processors of even 10 years ago, so this omission
is slowing the system down.
It is the default.
Since Fedora 34:
https://fedoramagazine.org/fedora-workstation-34-feature-focus-btrfs-tran...
7) Keep the last 3 update snapshots, not just the last 3 kernels.
This
would keep backout scenarios a lot more consistent and functional.
You can set this up with any of the various snapshot management tools
above. I'm not convinced that snapshots like this are great, since
there's also other non update data taking place potentially, and rolling
back could mess those things up. I suppose it's less likely on a
workstation than a server.
If I look at the changes coming in Fedora 38, I am disappointed in
the lack
of innovation. All of these items should be in there to make the system
cleaner, better and faster. Most of these asks have already been in SUSE
for many years now, and are well debugged and understood. Fedora is
supposed to be leading the way at the edge, not way behind it. Or am I
missing something about the politics of the distro?
There's no politics here. If you feel stongly that something should be
implemented, feel free to work on implementing it, or convincing others
to do so.
Hope that helps,
kevin