search

hunleyd / btrfs-auto-snapshot

BTRFS Automatic Snapshot Service for Linux
GNU General Public License v2.0
16 stars 4 forks source link

Improve compatibility with subvolume layouts. #9

Closed ams-tschoening closed 2 years ago

ams-tschoening commented 2 years ago

Am maintaining mountpoints and their associated subvolumes now, so that those subvolumes can be ignored when calculating all subvolumes available. I've tried openSUSE Leap 15.4 as it uses @ subvolumes and parent-child hierarchies like for /usr/local vs. @/usr/local. Additonally added /btrfs_test like I need on my own. Changed deleting subvolumes based on the currently hard-coded naming convention using /.btrfs/-directories, as that was the easiest to filter snaps vs. subvolumes. The problem ist that list always returns both, but when deleting the context should be clear that we only need snaps and only get those for the already given subvolume.

image

Fix were pretty difficult with mapping subvols to paths in the file system, having something like /@/usr/local when reading mountpoints vs. BTRFS-tools themself only provide @/usr/local etc. So there might still be some bugs, though it seems to work for me currently.

This fixes https://github.com/hunleyd/btrfs-auto-snapshot/issues/8.

ams-tschoening commented 2 years ago

There's still one problem left I need to check. Sometimes during creation of snaps I get the following error message:

localhost:/usr/local/btrfs-auto-snapshot # ./btrfs-auto-snapshot --keep=50 //
localhost:/usr/local/btrfs-auto-snapshot # ./btrfs-auto-snapshot --keep=2 //
ERROR: invalid snapshot name '/'
localhost:/usr/local/btrfs-auto-snapshot # ./btrfs-auto-snapshot --keep=20 //

When deleting snaps, I sometimes get the following as well:

localhost:/usr/local/btrfs-auto-snapshot # ./btrfs-auto-snapshot --keep=5 //
ERROR: Could not destroy subvolume/snapshot: Directory not empty
ERROR: Could not destroy subvolume/snapshot: Directory not empty
[...]

I think both are related and sometimes snaps are created in the wrong level, resulting in additional directories where snaps only are expected. Deleting snaps containing directories with additional snaps fails at some point. Others have reported similar issues:

https://www.reddit.com/r/btrfs/comments/agd6mr/btrfs_bug_in_snapshot_nameing/

I think this might be related to something I observed in the past already: Timestamps used in snap names are only per minute, so when executing multiple snaps within the same minute, calculated directory names overlap. In my past Ubuntus this resulted in some error message about read-only file systems, but maybe this has changed with newer versions of BTRFS and additional directories are created automatically instead.

hunleyd commented 2 years ago

have you had a chance to test this pr @mwt ? does it solve the issue you reported?

mwt commented 2 years ago

have you had a chance to test this pr @mwt ? does it solve the issue you reported?

Hi, sorry for not getting back earlier. I was swamped with some tasks. I just tried the PR. It's working for me. It works the way I'd expect too in terms of the nesting.

Thanks for working this out @ams-tschoening!

ams-tschoening commented 2 years ago

Broke it, fixed it?! ;-)

hunleyd commented 2 years ago

no worries @mwt and thanks for both the initial report and testing the PR!