autosnap = no is not respected

[serge-vk]

Hi there,

I have the configuration listed below and the data set using the production template works as expected. However, the data set based on the backup template also gets automatic snapshots. I tried a few times to wipe them out and run sanoid --cron. In this case, no snapshots were created, but when sanoid is run automatically through the timer/service, I always get automatic snapshots where they should not be taken. I wonder what may be wrong.

[rpool/USERDATA]
        use_template = production
        recursive = zfs
[back-up/Ubuntu]
        use_template = backup
        recursive = zfs

[template_production]
        autosnap = yes
        autoprune = yes
        frequently = 0
        hourly = 12
        ... 
[template_backup]
        autoprune = yes
        autosnap = no
        frequently = 0
        hourly = 24
        ...

[phreaker0]

run sanoid with --debug and post the output pls.

[serge-vk]

Hi there, thank you for responding. I have just run sudo sanoid --debug (see attached)
Sanoid debug output.zip
I can run it with the options used for the services as well, if necessary.
I also tried to specify autosnap = no and autoprune = yes in the data set configuration [back-up/Ubuntu], there is no difference.

By the way, in the debug output I can see an interesting setting:

$VAR1 = {
          'back-up/Ubuntu' => {
                                'autoprune' => 1,
                                'autosnap' => [
                                                'no',
                                                'no'
                                              ],

Would it not be expected to see 'autosnap' => 0 here?
Also, I noticed that a child of the data set bpool/BOOT that has autosnap on has the following:

          'bpool/BOOT/ubuntu_r44sdr' => {
                                          'autoprune' => 1,
                                          'autosnap' => 0,

[phreaker0]

you also have the following in the debug output:

duplicate key 'autosnap' in section 'template_backup', using the value from the first occurence and ignoring the others.

can you post your full sanoid config?

Also no snapshots are taken in the provided debug output. Please also post a debug run from the timer where snapshots are taken wrongfully.

[serge-vk]

I did not notice that duplicated 'autosnap'. What I have done now is I looked through the configuration and I left just what you see above. After that, I no longer see this 'autosnap' => ['no', 'no']. Also, I do not get snapshots on the back-up/Ubuntu data set any more. Therefore, it looks like this array instead of a single numerical value may have been upsetting the snap-shot logic. Sanoid made a note about that duplication, but I do not think it performed a proper action because it was just the opposite (maybe, double negation makes it positive?).

However, in the debug output I still see the following:

'rpool/ROOT' => {
                            'autoprune' => 1,
                            'autosnap' => 1,
. . .
'rpool/ROOT/ubuntu_r44sdr' => {
                                          'autoprune' => 1,
                                          'autosnap' => 0,
. . .

Actually, although rpool/ROOT is set to autosnap = yes, the debug output shows all its child data sets set to 'autosnap' => 0. Despite that, I do get snap-shots of all the children.

There seems to be two issues, then. One is probably related to duplicated autosnap = no and the other one to reporting the autosnap setting in debug output.

I have now tried making once more a duplicate setting in [template_backup]. Lo and behold, immediately I started getting snapshots in the data set using this template!

[phreaker0]

please post your original full sanoid config. This ways I should be able to reproduce the parse stuff and probably fix them.

[serge-vk]

I have attached the problematic configuration. Also note that even after I resolved the problem by removing a duplicate autosnap = no setting, I still have debug output that does not correspond to the real configuration (though Sanoid does what I want in that case).

sanoid.conf.txt

[phreaker0]

I did not notice that duplicated 'autosnap'. What I have done now is I looked through the configuration and I left just what you see above. After that, I no longer see this 'autosnap' => ['no', 'no']. Also, I do not get snapshots on the back-up/Ubuntu data set any more. Therefore, it looks like this array instead of a single numerical value may have been upsetting the snap-shot logic. Sanoid made a note about that duplication, but I do not think it performed a proper action because it was just the opposite (maybe, double negation makes it positive?).

Yes it was because of the invalid config (duplicate key). In case of the template section it wasn't handled (discarding the duplicate keys and only using the first one) despite the warning message.

However, in the debug output I still see the following:

'rpool/ROOT' => {
                            'autoprune' => 1,
                            'autosnap' => 1,
. . .
'rpool/ROOT/ubuntu_r44sdr' => {
                                          'autoprune' => 1,
                                          'autosnap' => 0,
. . .

Actually, although rpool/ROOT is set to autosnap = yes, the debug output shows all its child data sets set to 'autosnap' => 0. Despite that, I do get snap-shots of all the children.

This is the expected behaviour because you used "recursive = zfs". The child datasets won't be snapshotted by sanoid but by the recursive call to zfs.

There seems to be two issues, then. One is probably related to duplicated autosnap = no and the other one to reporting the autosnap setting in debug output.

Only the first one is relevant and it's basically a configuration failure which wasn't probably handled despite the warning message. The second one is the proper behaviour.

I have now tried making once more a duplicate setting in [template_backup]. Lo and behold, immediately I started getting snapshots in the data set using this template!

I made a PR which fixes this cases of misconfiguration.

[serge-vk]

Thank you, this is much appreciated.