BTRFS Stuck Subvolume

[adapterer]

Hi,

Using brtfs and VAL on Ubuntu 18.04, I seem to have some stuck subvolumes/snapshots that I can't remove?

Code: Select all

me@foo:~$ sudo btrfs subvolume list /
[sudo] password for me:
ID 257 gen 1777723 top level 5 path @
ID 258 gen 1777723 top level 5 path @home
ID 1521 gen 1777649 top level 257 path .snapshots
ID 2303 gen 1530137 top level 5 path .veeam_snapshots/{499f5c08-cc9b-470a-8857-e18e68e32a0e}/5_
ID 2304 gen 1530139 top level 5 path .veeam_snapshots/{499f5c08-cc9b-470a-8857-e18e68e32a0e}/257_@
ID 2305 gen 1530140 top level 5 path .veeam_snapshots/{499f5c08-cc9b-470a-8857-e18e68e32a0e}/258_@home
ID 2306 gen 1530140 top level 5 path .veeam_snapshots/{499f5c08-cc9b-470a-8857-e18e68e32a0e}/278_@apt-snapshot-release-upgrade-bionic-2018-04-28_08:07:51
ID 2313 gen 1776129 top level 1521 path .snapshots/1/snapshot
ID 2314 gen 1776166 top level 1521 path .snapshots/2/snapshot
ID 2315 gen 1776249 top level 1521 path .snapshots/3/snapshot
ID 2316 gen 1776353 top level 1521 path .snapshots/4/snapshot
ID 2317 gen 1776470 top level 1521 path .snapshots/5/snapshot
ID 2318 gen 1776580 top level 1521 path .snapshots/6/snapshot
ID 2319 gen 1776684 top level 1521 path .snapshots/7/snapshot
ID 2320 gen 1776716 top level 5 path @apt-snapshot-2020-02-19_15:16:58
ID 2321 gen 1776717 top level 1521 path .snapshots/8/snapshot
ID 2322 gen 1777648 top level 1521 path .snapshots/9/snapshot

When I try to delete:

Code: Select all

me@foo:~$ sudo btrfs subvolume delete .veeam_snapshots/{499f5c08-cc9b-470a-8857-e18e68e32a0e}/5
ERROR: cannot access subvolume .veeam_snapshots/{499f5c08-cc9b-470a-8857-e18e68e32a0e}/5: No such file or directory

I only noticed because my OS volume had hundreds of snapshots from VAL and filled up the volume - luckily this is only a homelab.

I also notice they are not listed under snapper?

Code: Select all

me@foo:~$ sudo snapper list
Type   | #  | Pre # | Date                          | User | Cleanup  | Description | Userdata
-------+----+-------+-------------------------------+------+----------+-------------+---------
single | 0  |       |                               | root |          | current     |
single | 1  |       | Wed 19 Feb 2020 10:00:00 AWST | root | timeline | timeline    |
single | 2  |       | Wed 19 Feb 2020 10:23:05 AWST | root | number   | boot        |
single | 3  |       | Wed 19 Feb 2020 11:00:01 AWST | root | timeline | timeline    |
single | 4  |       | Wed 19 Feb 2020 12:00:01 AWST | root | timeline | timeline    |
single | 5  |       | Wed 19 Feb 2020 13:00:01 AWST | root | timeline | timeline    |
single | 6  |       | Wed 19 Feb 2020 14:00:01 AWST | root | timeline | timeline    |
single | 7  |       | Wed 19 Feb 2020 15:00:01 AWST | root | timeline | timeline    |
pre    | 8  |       | Wed 19 Feb 2020 15:16:58 AWST | root | number   | apt         |
post   | 9  | 8     | Wed 19 Feb 2020 15:20:21 AWST | root | number   | apt         |
single | 10 |       | Wed 19 Feb 2020 16:00:01 AWST | root | timeline | timeline    |

[PTide]

Hi,

Looks unexpected. If you're not on v4.0 yet, then please try v4.0 and see if the issue persists.

Thanks

[adapterer]

VAL 4.0 didnt fix it, but I managed to resolve this for anyone who's interested.

To fix it you have to mount the '/' subvolume under a temporary path:

Code: Select all

sudo mount -o subvol=/ /dev/sdc1 /mnt/tmp

I could then delete the snapshots from there:

Code: Select all

sudo btrfs sub d /mnt/tmp/.veeam_snapshots/{0badfe1b-8109-4867-8260-948cc63fa112}/5_

Then just cleanup the mounted subvolume:

Code: Select all

sudo umount /mnt/tmp

Cheers

[PTide]

I double-checked something with out team. Turns out that those snapshots are for change-block tracking - 1 snapshot per subvolume. That is, you shouldn't delete them : )

I'll file a change request for renaming so that those snapshots are named in a more obvious way.

Thanks!

[adapterer]

Huh, right you are - they're back. Forget I said anything I guess

EDIT: I should also mention that I think I figured this out. I tried to troubleshoot some failed backups a while ago and gave up (homelab laziness) . In the midst of troubleshooting I installed snapper, a btrfs snapshot management utility, which by default applies a snapshot policy which I think was the cause of the root volume filling up, not VAL.

Appreciate the support anyhow, VAL and VAW are amazing products