Possible bug in schnapps: Can't change the root directory with -d

Software SW bugs discussion
1

When I run a command like
schnapps -d /srv/lxc/ create "/srv/lxc: 2021-01-06",
I’m getting a snapshot from the root (/) directory and not from the directory /srv/lxc.

I’m using TurrisOS 5.1.4 on a Turris Omnia Router 2019 with root installed on an internal SSD and a second partition (/dev/sda2) mount on /srv/lxc. The second partition is formated with btrfs and mounted via /etc/config/fstab with the following config lines:

config mount
option uuid ‘d8445935-7fc5-4c7e-9ebc-7d20c5e86587’
option target ‘/srv/lxc’
option fstype ‘btrfs’
option options ‘rw,noatime,ssd,space_cache,commit=5,subvol=/lxc’
option enabled ‘1’

The configuration file /etc/config/schnapps contains the lines:

config keep 'keep'
       option max_single '-1'
        option max_time '5'
        option max_updater '5'
        option max_rollback '3'

config remote 'remote'
#        option url 'nextcloud://cloud.example.com'|'webdav://dav.example.com'
#        option path '/turris/backups'
#        option user 'myself'
#        option password 'password'
        option sync_types 'single,time'

#config encrypt 'encrypt'
#        option pass 'password'
2

From what I can comprehend, schnapps currently does not handle subvolumes created outside the assumed default /@ subvolume and it can only create snapshots of the whole /@ subvolume: https://gitlab.nic.cz/turris/schnapps/-/blob/master/schnapps.sh#L318

And that may be the problem you are facing, if your subvolume /lxc is actually not located under /@ subvolume. But I’m afraid that’s where my knowledge ends, as I’m still new to this Btrfs world.

You could maybe try looking at btrfs filesystem show /srv/lxc to see if it returns expected /dev/sda2 device and also btrfs subvolume list /srv/lxc -a -p -t might be helpfull to see which subvolumes are present at that path and who’s their parent

1 Like
3

I’ve changed the following line in /etc/config/fstab:
option options ‘rw,noatime,ssd,space_cache,commit=5,subvol=/lxc’
to:
option options ‘rw,noatime,ssd,space_cache,commit=5,subvol=/@’
renamed the subvolume /lxc to /@ and rebooted the system. But the result is still the same: schnapps created a snapshot from the root system and not from /srv/lxc.

the command btrfs filesystem show /srv/lxc outputs:

Label: none  uuid: d8445935-7fc5-4c7e-9ebc-7d20c5e86587
Total devices 1 FS bytes used 2.64GiB
devid    1 size 100.00GiB used 5.01GiB path /dev/sda2

and the command btrfs subvolume list /srv/lxc -a -p -t returns:

ID      gen     parent  top level       path
--      ---     ------  ---------       ----
257     16764   5       5               <FS_TREE>/@
261     886     257     257             @/old
:

In my opinion that looks good, but doesn’t work :frowning:
It looks similar to the output of btrfs subvolume list / -a -p -t:

ID      gen     parent  top level       path
--      ---     ------  ---------       ----
259     310     5       5               <FS_TREE>/certbackup
270     373     5       5               <FS_TREE>/@1
275     375     5       5               <FS_TREE>/@
4

Isn’t that the goal? Using schnapps -d /srv/lxc create "description" should snapshot /@ into /@1 on the target filesystem. I just tested this on my Omnia with a similar setup and it worked as expected.

1 Like
5

Due to the documentation of schnapps I think, that it should take a snapshot of /srv/lxc and because it is on a different partition than the root file system, it must put it at /srv/lxc/@1 or somewhere else in the partion of /srv/lxc. I think, that schnapps is a script which uses the btrfs subvolume snapshot ... command. The btrfs command is only able to build a snapshot in the same partition.

You can check the content of your snapshot by exporting it with schnapps. You will than see, that it is a smapshot from root and not (and also not including) a snapshot from /srv/lxc.
This behaviour makes snapshot useless for backing up another partition than the root partition.

.

6

Maybe there’s a misunderstanding in how schnapps works: the -d switch doesn’t specify a directory to snapshot but a device (which holds a BTRFS filesystem) which is mounted at the specified mountpoint. In your case, if you mount -o subvol=/@ /dev/sda2 /srv/lxc then schnapps -d /srv/lxc create "description" will create /@1, /@2 and so on on /dev/sda2. These subvolumes/directories are siblings of /@ which you mounted, not its children. Hence, these snapshots won’t show up under /srv/lxc. You can access them, e.g., by mounting their common parent subvolume: mount -o subvol=/ /dev/sda2 /mnt. Also, schnapps -d /srv/lxc list should list them correctly and these snapshots should contain whatever was in /srv/lxc (assuming it was mounted as mentioned above).

1 Like
7

I know that -d must specify a mount point of a BTRFS filesystem and that is that, what I’m using. Something else must be wrong.

If I run the command mount -o subvol=/ /dev/sda2 /mnt and then the command ls /mnt I will see only the directory @ and no snapshot directories.
I’ve checked this also with the command btrfs subvolume list /srv/lxc/, which lists all subvolumes under /srv/lxc. In this output list are also no /@1, /@2 and so on subvolumes. Only /@ and other subvolumes, which I’ve created with btrfs, are listed.
But the /@* subvolumes are all listed in the root partition parallel to the snapshots I took with the command schnapps create.

This command lists all snapshots I’ve taken - regardless if I’ve used the -d option or not. And the list is the same as the one of the command schnapps list.

So whatever the reason is, the -d option has no effect on my system or at least in the way I’m using it.

@dhopfm Is this different on your system?

Maybe, that it has something to do with my special setup (I’m booting from /dev/sda1). Here is the output of the command mount | grep /dev/sd:

/dev/sda1 on / type btrfs (rw,noatime,ssd,space_cache,commit=5,subvolid=270,subvol=/@)
/dev/sda2 on /srv/lxc type btrfs (rw,noatime,ssd,space_cache,commit=5,subvolid=257,subvol=/@)
8

Yes, I reproduced your setup and it’s working fine. But shouldn’t be too hard to debug. Can we start with checking the version you have installed? opkg list-installed schnapps should yield 2.3-1. There is a recent patch that might be relevant.

1 Like
9

Yes, thanks for you support. I’ve the same version.

On my system I’ve also a file /etc/schnapps/config with the following content:

ROOT_DEV=“/dev/sda1”

I just found out that this is what is causing my problem. Without this line, it works as it should. I added the line due to the (outdated) document on setting up an SSD as a boot (and root) device. It seems that this is no longer necessary.
Sorry for not mentioning this earlier, but in my opinion a program option should always override a configuration file. So I thought that this file may not be the cause of the problem.
Now I think there is indeed a bug in schnapps - but only a small one.

Many thanks for your help. Open source software is really great, but it can only really come into its own with a strong community.

10

Great it’s working now! The bug was fixed in the commit I mentioned above. I guess it should make it into one of the next Turris updates. Otherwise, you could also move that line yourself quite easily in the /usr/bin/schnapps script.

1 Like
11

Fine.

I’ve now another problem. The output of the command schnapps -d /srv/lxc/ list contains the following line:

ERROR: can’t list qgroups: quotas not enabled

@dhopfm Do you see this line too? The reason for that is probably not schnapps but who knows.

12

Try issuing btrfs quota enable /srv/lxc once, that should fix the issue permanently. Schnapps doesn’t honor -d when checking whether quotas are enabled, I will filed an issue to fix that.

1 Like
13

That fixed it, thanks.