Default flatpak subvolume?

Discussion Move from: Default flatpak subvolume?

Fedora by default provides the ability to install flatpak applications, easy to install, from GNOME Software or Plasma Discover.
The flatpak subvolume would be very convenient for many users who use Btrfs snapshots, with some advantages:

  • Restoring the snapshot does not restore the flatpak applications installed after the snapshot.
  • Backup with btrfs send
  • Set compression with zstd algorithm or other ‘btrfs set property

Maybe it makes sense to have “var/log” on a separate subvolume as well? in case of problems and recovery, you can still read the logs.
Nothing, I thought about it and not knowing where to write these proposals, I wrote them here.

I add to the discussion:

In addition to “/var/lib/flatpak” and “/var/log”, are these folders sure to exclude?
/var/tmp:

5.15. /var/tmp : Temporary files preserved
between system reboots
5.15.1. Purpose
The /var/tmp directory is made available for programs that require temporary files or directories that
are preserved between system reboots. Therefore, data stored in /var/tmp is more persistent than data
in /tmp.
Files and directories located in /var/tmp must not be deleted when the system is booted. Although data
stored in /var/tmp is typically deleted in a site-specific manner, it is recommended that deletions occur
at a less frequent interval than /tmp.

/var/lib/libvirt:
Contains images and configurations created with Virt-Manager

/var/cache:

5.5. /var/cache : Application cache data
5.5.1. Purpose
/var/cache is intended for cached data from applications. Such data is locally generated as a result of
time-consuming I/O or calculation. The application must be able to regenerate or restore the data. Unlike
/var/spool, the cached files can be deleted without data loss. The data must remain valid between
invocations of the application and rebooting the system.
Files located under /var/cache may be expired in an application specific manner, by the system
administrator, or both. The application must always be able to recover from manual deletion of these files
(generally because of a disk space shortage). No other requirements are made on the data format of the
cache directories.
Rationale
The existence of a separate directory for cached data allows system administrators to set different
disk and backup policies from other directories in /var.

Source: https://refspecs.linuxfoundation.org/FHS_3.0/fhs-3.0.pdf

I have been using this configuration for many years, performing snapshots and restores without problems.
The advantage is that you would save space if you make a snapshot on the root volume and I see no against.

I also have the problem that a nested var/lib/machines volume is created, even this could be put on the toplevel with the installer?
Even if I remove it, I don’t know who creates it, but I always find it.

1021 4145772 941 var/lib/machines

This is as currently Fedora, from 33.
Same configuration, with some changes here and over time, on Ubuntu for years.
I have never found problems.

emanu@fedora ~> sudo btrfs subvol list -t /
[sudo] password di emanu: 
ID	gen	top level	path	
--	---	---------	----	
261	4145770	5		var_lib_flatpak
933	4145799	5		@home
941	4145792	5		@
942	4145797	5		var_log
943	4145779	5		var_tmp
944	4145775	5		var_cache
947	4145418	5		libvirt_homeuser
951	4145772	5		var_lib_libvirt
1016	4144781	5		timeshift-btrfs/snapshots/2021-10-26_22-00-01/@
1020	4144781	5		timeshift-btrfs/snapshots/2021-11-02_20-07-38/@
1021	4145772	941		var/lib/machines
1022	4144812	5		timeshift-btrfs/snapshots/2021-11-03_20-00-01/@
emanu@fedora ~> cat /etc/fstab

#
# /etc/fstab
# Created by anaconda on Mon Aug 23 18:24:18 2021
#
# Accessible filesystems, by reference, are maintained under '/dev/disk/'.
# See man pages fstab(5), findfs(8), mount(8) and/or blkid(8) for more info.
#
# After editing this file, run 'systemctl daemon-reload' to update systemd
# units generated from this file.
#
UUID=1dfbd78c-313d-44a6-9612-2c7b45bed032 /                       btrfs   noatime,compress=zstd:1,autodefrag,subvol=@ 0 0
UUID=4323-EA93          /boot/efi               vfat    umask=0077,shortname=winnt 0 2
UUID=1dfbd78c-313d-44a6-9612-2c7b45bed032 /home                   btrfs   noatime,compress=zstd:1,autodefrag,subvol=@home    0 0
UUID=1dfbd78c-313d-44a6-9612-2c7b45bed032 /var/cache              btrfs   noatime,compress=zstd:1,autodefrag,subvol=var_cache 0 0
UUID=1dfbd78c-313d-44a6-9612-2c7b45bed032 /var/lib/flatpak        btrfs   noatime,compress=zstd:1,autodefrag,subvol=var_lib_flatpak 0 0
UUID=1dfbd78c-313d-44a6-9612-2c7b45bed032 /var/lib/libvirt        btrfs   noatime,compress=zstd:1,autodefrag,subvol=var_lib_libvirt 0 0
UUID=1dfbd78c-313d-44a6-9612-2c7b45bed032 /var/log                btrfs   noatime,compress=zstd:1,autodefrag,subvol=var_log 0 0
UUID=1dfbd78c-313d-44a6-9612-2c7b45bed032 /var/tmp                btrfs   noatime,compress=zstd:1,autodefrag,subvol=var_tmp 0 0

Yep, I’m doing a similar thing for a long time now for the same reason: when you do a rollback you don’t want everything rolled back: home, logs, VM images, flatpaks.

Questions, in no particular order:

  • should the subvolumes be created by the installer? Traditionally, it is the role of the installer to do partitioning layout things. And importantly, Anaconda has the ability to do it.

  • the drawback of only the installer creating the layout is, what to do about upgrades? We’d need clean installs to change the layout. That means we have to put a lot more thought into the layout, because we don’t want to be changing it every (other) release, because all the layouts have to be supported for at least two releases.

    • could there be an atomic directory → subvolume conversion? Yes. It could easily be done with shell script already today, but something robust and not prone to racing is necessary; it needs to be as reliable as sytsemd-offline-updates. (e.g. functionality provided by libbtrfs or kernel ioctl? Would systemd-repart be the best place to leverage it?)
  • naming convention and discovery. Currently it makes us more dependent on /etc/fstab, while also complicating it. Is there another way? A systemd-btrfs-subvol-generator perhaps?

1 Like

To be specified as I write from a passionate user and not an expert.

I am of the opinion that it must be created by the installer, if the user chooses the automatic installation, must have all the convenience ready.

I think the layouts during the upgrade should not change, so as to avoid extra work and various problems.
The user who wants to go to the new layouts can do it when he wants.
I don’t see Nessu Ncontro because this is just a millemermination for users who use snapshots or btrfs send

I think the layouts during the upgrade should not change, so as to avoid extra work and various problems.
The user who wants to go to the new layouts can do it when he wants.
I see Nessu Ncontro because this is just a millemermination for users who use snapshots or Btrfs Send.
To date Fedora not active and does not provide any tool for snapshots, I hope this changes to the benefit of many users soon.
Some users helping Fedora in the Italian group, which I guided in this layouts and used Timeshift, have exploited during the upgrade or other situations, the comfort isnapshot comfort just a click away, thanks to Timeshift. I hope it becomes an advantage for all users who use Fedora with BTRFS and is why I opened this discussion.