Describe the bug
Hi, I started to use Timeshift for system btrfs snapshots of one recent Mint installation, is first time I use timeshift on a production system with btrfs, I use btrfs for more than a decade, but I have always used other software for snapshots.
Outside the subvolumes layout and not optimal mount flags, which however concern the low btrfs support in the installer, and which I had manually workaround after installation, I noticed that the toplevel mount created by Timeshift to manage snapshots does not consider the flags used by the system mount.
I mean the mount it has done on /run/timeshift/xxxx/backup that use the default flag that may be different from the ones used for the / mount, for example relatime->noatime, the compression etc...
For most operations, I don't think it's a problem because, if I'm not mistaken, these parameters impact writes made to that mount, while the data remains as is when a snapshot is created. However, for write operations made to that mount, for example, using relatime (the default) instead of noatime (one of the most commonly used optimizations) will generate more metadata even just for a simple "consultation" of the snapshots.
The other btrfs snapshot management software I know of either requires an existing toplevel mount (where you set the "right" mount options) or creates nested snapshots (the latter has significant drawbacks, however) and therefore does not create its own mounts.
Expected behavior
Use the mount flag of / for the top level, or maybe more simply you could at least add in the settings the possibility to specify a "fixed" toplevel mount (with a security check that verifies that it is correct)
System:
- Linux Distribution Name and Version: Mint 22.1
- Desktop: Cinnamon
- Application Version: 24.06.6
Describe the bug
Hi, I started to use Timeshift for system btrfs snapshots of one recent Mint installation, is first time I use timeshift on a production system with btrfs, I use btrfs for more than a decade, but I have always used other software for snapshots.
Outside the subvolumes layout and not optimal mount flags, which however concern the low btrfs support in the installer, and which I had manually workaround after installation, I noticed that the toplevel mount created by Timeshift to manage snapshots does not consider the flags used by the system mount.
I mean the mount it has done on /run/timeshift/xxxx/backup that use the default flag that may be different from the ones used for the / mount, for example relatime->noatime, the compression etc...
For most operations, I don't think it's a problem because, if I'm not mistaken, these parameters impact writes made to that mount, while the data remains as is when a snapshot is created. However, for write operations made to that mount, for example, using relatime (the default) instead of noatime (one of the most commonly used optimizations) will generate more metadata even just for a simple "consultation" of the snapshots.
The other btrfs snapshot management software I know of either requires an existing toplevel mount (where you set the "right" mount options) or creates nested snapshots (the latter has significant drawbacks, however) and therefore does not create its own mounts.
Expected behavior
Use the mount flag of / for the top level, or maybe more simply you could at least add in the settings the possibility to specify a "fixed" toplevel mount (with a security check that verifies that it is correct)
System: