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-transparent-compression/ > 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
Attachment:
signature.asc
Description: PGP signature
_______________________________________________ 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
