noatime option

Bug #1569724 reported by Tomasss
80
This bug affects 16 people
Affects Status Importance Assigned to Milestone
apt-btrfs-snapshot (Ubuntu)
Confirmed
Undecided
Unassigned

Bug Description

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

Revision history for this message
Launchpad Janitor (janitor) wrote :

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

Changed in apt-btrfs-snapshot (Ubuntu):
status: New → Confirmed
Revision history for this message
Gilles Schintgen (shigi) wrote :

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.)

Revision history for this message
Alex Malinovich (alexmalinovich) wrote :

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.

Revision history for this message
Martin (martin-leitner) wrote :

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.

Revision history for this message
Martin (martin-leitner) wrote :

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.

Revision history for this message
Dark Dragon (darkdragon-001) wrote :
Revision history for this message
Halvor Lyche Strandvoll (halvors) wrote :

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

Revision history for this message
Halvor Lyche Strandvoll (halvors) wrote :

Is this getting any attention at all?

Revision history for this message
Jürgen Hörmann (hoermannn.j) wrote :

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.

Revision history for this message
Jürgen Hörmann (hoermannn.j) wrote :

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.

Revision history for this message
Dark Dragon (darkdragon-001) wrote :

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.

Revision history for this message
Jonathan (jjcf89) wrote :

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.

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.