On Feb 24, 2023, at 09:31, John Mellor <john.mellor@xxxxxxxxx> wrote: > > Ok, I'm anticipating a firestorm of BS responses on this, but here goes anyway. Nice. So you can casually disregard any comment right away. Clever. > 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. I believe there have been issues with this, such as the relative size of the btrfs grub2 module making it difficult to fit in the MBR blocks used as a first stage bootloader. (You need enough code to find the kernel and initrd) Not an issue with UEFI as far as I know, although you’ll still need a separate fat32 volume for that. I think the issue has to do with the kernel update tools, but I haven’t followed the tickets. > 2) When are we going to see timeshifting tools built into the desktop, ala Solaris? That's incredibly useful for developers. No idea what that is. I know there are tools that use the name timeshidt that auto-create snapshots during updates, but you need specific volume names and Fedora doesn’t do that. > 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? Not a windows user, so I have no idea what you’re talking about there. It seems that people call something “windows-like” when they don’t like it, even if it has no passing resemblance. (Such as how people called systemd windows like!?!) I assume you’re talking about the offline update that Fedora uses? I’ve found it absolutely necessary, since many GNOME components (and other DEs) can crash when libraries update under them. However, there is absolutely an atomic update process very similar to what you are asking about. I suggest looking into Silverblue (GNOME) and Kinoite (KDE). > 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. I’m not sure which backup tools you’re talking about. Deja-dup is a user space backup tool and not suited for snapshot backup. And btrfs has it’s own equivalent of dump/restore. Without an effective built in encryption, using ‘btrfs send‘ to store offsite backups will require some other tools to protect the data. So for now, we use the user space backup tools. > 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. You are mistaken if you think that btrfs has built in encryption. Maybe soon. I look forward to when it is upstreamed into the kernel. > 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. Fortunately this can be added after the fact. I’m not sure it makes sense for everyone to have compression enabled by default. It would likely have a performance impact in some cases and people would yell and scream if it was enabled everywhere. Perhaps a knob to enable it in the installer? > 7) Keep the last 3 update snapshots, not just the last 3 kernels. This would keep backout scenarios a lot more consistent and functional. This seems like the same point as the second point about snapshots. Look into silverblue, seriously. -- Jonathan Billings _______________________________________________ users mailing list -- users@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to users-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
