noatime option

[Tomasss]

apt-btrfs-snapshot 0.3.4.2 on LinuxMint Xfce 17.3 Rosa (based on Ubuntu 14.04.3 LTS)
my fstab:
/dev/sda5 / btrfs defaults,compress=lzo,noatime,nodiratime,space_cache,subvol=@ 0 1

# apt-btrfs-snapshot list-older-than 10d
Available snapshots older than '10d':
Error: fstab option 'noatime' incompatible with option

After deleted noatime option in fstab
# apt-btrfs-snapshot list-older-than 10d
Available snapshots older than '10d':
@apt-snapshot-2016-03-22_15:39:00

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Gilles Schintgen (shigi)]

I've stumbled upon the same issue.

Here's what I found:

https://answers.launchpad.net/ubuntu/+source/apt-btrfs-snapshot/+question/263994

https://bugs.launchpad.net/ubuntu/+source/apt-btrfs-snapshot/+bug/833980

In my opinion "older than" should NOT imply "last accessed/used". Such a feature should be taken care of separately / optionally. I'd guess that most users use apt-btrfs-snapshot exclusively in order to revert their system in case of an update gone wrong. In this use case, atime is of no practical use whatsoever. (Of course some users will use apt-btrfs-snapshot to switch between different versions of their OS and this should be supported, but preferably not at the expense of the "main" feature.)

[Alex Malinovich (alexmalinovich)]

To further illustrate how ridiculous this is, I've updated /etc/cron.weekly/apt-btrfs-snapshot to make a backup of fstab, remove all occurrences of noatime, run apt-btrfs-snapshot delete-older-than, and then move the original fstab back into place.

I understand that there are legitimate concerns around determining the age of a snapshot, but as things stand right now the "fix" in #833980 only served to annoy legitimate users while providing no actual protection whatsoever.

[Martin (martin-leitner)]

In Bug #833980 Dark Dragon writes: "I think it is better to parse the snapshot name, since it includes the creation time anyway. Feel free to review my changes"

Sounds like a good solution to me, but seems to be still not implemented yet.
I'm using Kubuntu 18.10 with a btrfs root partition.
If I miss to delete older snapshots for some months (which is very annoying, because I have to delete every snapshot manually), then the partition gets filled up and Kubuntu can't boot any more. So then I have to boot with CD, delete snapshots and everything returns to normal. I would prefer to use "apt-btrfs-snapshot delete-older-than 10d" e.g. in chron.daily, but switching off noatime is definitely no choice, since this is not recommended for ssd.

[Martin (martin-leitner)]

This bug is still open in Kubuntu 20.04!

A solution for people using SSD (I think today it's the vast majority) and therefore using "noatime" is still missing.

[Dark Dragon (darkdragon-001)]

I fixed this almost three years ago: https://github.com/darkdragon-001/apt-btrfs-snapshot/commit/83f6f9d9ca2557b7f0225a7d3fbffd107cd207c4

But merge requests are just ignored: https://code.launchpad.net/apt-btrfs-snapshot/+activereviews

I am just using my own version since a couple of years: https://launchpad.net/~darkdragon-001/+archive/ubuntu/ppa

[Halvor Lyche Strandvoll (halvors)]

Please do fix this, this is long overdue :-(

[Halvor Lyche Strandvoll (halvors)]

Is this getting any attention at all?

[Jürgen Hörmann (hoermannn.j)]

Hello Michael, I Subscribed you to this issue because you are the maintainer of the package as stated here: https://www.ubuntuupdates.org/package/core/groovy/universe/base/apt-btrfs-snapshot

as @darkdragon-001 stated he created a PR for this that does not rely on atime but on the filestamp in the snapshot name. Unfortunately he filed his PR against an inofficial fork.

I did not find the original repository that is the source for the Ubuntu package. Can you help out here. Where do we need to sent the PR or patch to?

I'm hit by this bug too and I'd help to resolve this.

[Jürgen Hörmann (hoermannn.j)]

In Bug #833980 Michael Vogt writes:

> I added some code into trunk now that will detect noatime and simply bail out for now. We need a more clever way of detecting the snapshots age in this case. The code must ensure that it detects when a snapshot was booted last, not when it was taken.

Maybe that is the reason for not merging Dark Dragons code. On the other Hand we really need a solution for all the SSD users around today.

[Dark Dragon (darkdragon-001)]

As mentioned in the linked thread, I still don't get why we need to know when a snapshot was booted last. The only thing I am interested in, was when it was created. I create my snapshots read-only. So when I want to _use_ a snapshot more than just booting once, I need to create a rw subvolume (as snapshot) of the snapshot anyway.

[Jonathan (jjcf89)]

Just use the parse the date from the snapshot name as Martin mentions. I'm going to uninstall this plugin as it has made my system unusable.