Bug 1223153

Summary:	snapper fails to create a btrfs snapshot if --cleanup-algorithm is used
Product:	[openSUSE] openSUSE Tumbleweed	Reporter:	slager <hslager>
Component:	Kernel:Filesystems	Assignee:	Wenruo Qu <wqu>
Status:	RESOLVED FIXED	QA Contact:	E-mail List <qa-bugs>
Severity:	Normal
Priority:	P5 - None	CC:	aschnell, ddiss, rgoldwyn, wqu
Version:	Current	Flags:	ddiss: needinfo? (hslager)
Target Milestone:	---
Hardware:	x86-64
OS:	openSUSE Tumbleweed
See Also:	https://bugzilla.suse.com/show_bug.cgi?id=1222816
Whiteboard:
Found By:	---	Services Priority:
Business Priority:		Blocker:	---
Marketing QA Status:	---	IT Deployment:	---

Description slager 2024-04-19 15:46:46 UTC

snapper fails to create a btrfs snapshot if --cleanup-algorithm is used, with at least kernel versions 6.8.4 to 6.8.6

It appears that on all my OSses (openSUSE Tumbleweed, Debian Bookworm, both x86_64 and aarch64) this is the case.

Recent discovery is after an zypper dup for a laptop which then installed the Tumbleweed kernel.
Before the update, with kernel 6.8.1-1-default, no problem.

Earlier bug report is with Tumbleweed rootfs on RK3588S hardware and Armbian provided kernel, see: https://forum.armbian.com/topic/37473-snapper-fails-to-create-a-btrfs-snapshot-if-cleanup-algorithm-is-used/

On Tumbleweed, snapper version is:
# snapper --version
snapper 0.10.7
libsnapper 7.4.0
flags btrfs,lvm,no-ext4,xattrs,rollback,btrfs-quota,selinux

On Debian Bookworm flavor, snapper version is:
# snapper --version
snapper 0.10.4
flags btrfs,lvm,no-ext4,xattrs,rollback,btrfs-quota,no-selinux

So far on the x86_64 laptop, I see in /var/log/snapper.log:
2024-04-18 18:48:26 WAR libsnapper(5811) Btrfs.cc(checkSnapshot):490 - CAUGHT: open failed path://.snapshots/536 errno:2 (No such file or directory)
2024-04-18 18:48:26 ERR libsnapper(5811) Btrfs.cc(createSnapshot):328 - create snapshot failed, btrfs_util_create_snapshot_fd2() failed, errno:2 (No such file or directory)

Comment 1 David Disseldorp 2024-04-20 00:13:01 UTC

Thanks for the report...

(In reply to slager from comment #0)
> snapper fails to create a btrfs snapshot if --cleanup-algorithm is used,
> with at least kernel versions 6.8.4 to 6.8.6
...
> So far on the x86_64 laptop, I see in /var/log/snapper.log:
> 2024-04-18 18:48:26 WAR libsnapper(5811) Btrfs.cc(checkSnapshot):490 -
> CAUGHT: open failed path://.snapshots/536 errno:2 (No such file or directory)
> 2024-04-18 18:48:26 ERR libsnapper(5811) Btrfs.cc(createSnapshot):328 -
> create snapshot failed, btrfs_util_create_snapshot_fd2() failed, errno:2 (No
> such file or directory)

At first glance it doesn't look like anything kernel related. Could you please provide your snapper configs? Are you only using snapper/zypper for snapshot management, or have you manually modified them via e.g. "btrfs subvolume ..."? CC'ing Arvin.

Comment 2 Arvin Schnell 2024-04-20 06:26:10 UTC

Already fixed, see https://github.com/openSUSE/snapper/issues/894.

Comment 3 slager 2024-04-20 06:38:38 UTC

(In reply to Arvin Schnell from comment #2)
> Already fixed, see https://github.com/openSUSE/snapper/issues/894.

OK, I was just typing a long story, but I'll read the github info and then I'll get it working again I think.

Comment 4 Wenruo Qu 2024-04-20 07:39:40 UTC

Oh, damn it, it's all my fault.

The problem is I didn't take the qgroup disabled case into consideration.

I'll fix the behavior, but I also very appreciate the fix from snapper side too.

Comment 5 slager 2024-04-20 08:12:21 UTC

OK, I was preparing/changing some script of mine doing all the hosts backup to remove the  '1/0' from the root snapper config file, but maybe I'll limit it to just the hosts that need latest/custom kernel. I see that the script works on one online host, but quite some are offline (and/or run older distro kernel).

I have disabled quotas, but for many hosts, I have copied some own template/config for snapper root filesystem from some new Tumbleweed install 2 years ago or so. I only tuned the cleanup times per host manually, did not touch the QGROUP lines.

For some older hosts, I have no QGROUP line or it is set to "". So that clarifies those hosts run/backup without issues in the last days.