Errata #4 notice gone without actually resolving the problem

[mtippmann]

System information

Type	Version/Name
Distribution Name	Debian + Arch
Distribution Version	stretch / current Arch
Linux Kernel	4.9.0-8-amd64 #1 SMP Debian 4.9.144-3.1 / 5.0.7-arch1-1-ARCH
Architecture	x86_64
ZFS Version	current git (b92f5d9f8254f72629However8a6ab962719fc2b68350b1) on Debian / zfs-dkms-git 2019.04.08.r5045.g9a65234c8-1 on Arch

Describe the problem you're observing

zpool status does not report errata 4 anymore - but the recommend action (recreating encrypted filesystems) was not done. Only the bookmarks_v2 feature was enabled on both pools.

Describe how to reproduce the problem

upgrade ZFS on an filesystem that reports errata 4 - probably reboot/restart os.

Include any warning/errors/backtraces from the system logs

there are no warnings and no problems, so far. However as the demanded action from errata 4 (https://zfsonlinux.org/msg/ZFS-8000-ER/) was not done I suspect the underlying problem may still exist.

A scrub makes no difference.

[JMoVS]

Did you use encrypted file systems?

[mtippmann]

Both pools have an encrypted dataset below the root and showed the notice in the past:

~ » zfs get encryption rpool
NAME   PROPERTY    VALUE        SOURCE
rpool  encryption  off          default
~ » zfs get encryption rpool/encr
NAME        PROPERTY    VALUE        SOURCE
rpool/encr  encryption  aes-256-ccm  -

[kliu128]

I can confirm having the issue. I upgraded to 0.8.0-rc4 and the warning has mysteriously disappeared.

[behlendorf]

The errata was specifically concerned with existing snapshots of encrypted filesystems. If you have an encrypted pool and have no snapshots of the encrypted filesystems (or have removed those snapshots) then there's no need for any further action. If zpool status doesn't report the errata then the issue was not detected in your pool.

[JMoVS]

Ok this is interesting. But why would I then need to destroy the dataset if deleting all snapshots could work? Or does it only work if no snapshots were created at all ever? The errata doesn‘t mention snapshots specifically, does it?

[behlendorf]

Deleting all the snapshots on the original source pool should be sufficient. The reason is that the fundamental fix for raw send issue was to associate an "IVset guid" with each snapshot. It acts as an identifier for the set of IVs used to encrypt a given snapshot and is now required during a raw receive. Since snapshot are immutable by design this "IVset guid" couldn't be associated with existing snapshots.

The errata will be reported in zpool status when either:

1. The bookmarks_v2 feature has not been enabled, or
2. A snapshot is detected without the required "IVset guid"

If nothing is reported then all the snapshots in your encrypted pool do include the "IVset guid". I hope that helps clear things up.

[JMoVS]

ah oh, so assuming I have rolling snapshots on the pool, this should mean that I don't have to recreate the pool because at some point, all old snapshots without an "IVset guid" will be rolled out and deleted. This is very good news for a pool where I keep limited number of snapshots!

[mtippmann]

@behlendorf thanks for the clarification! IMHO it's a documentation bug then - the instructions in the errata are not mentioning snapshots at all and also don't explain the problem in the same way as your comment and and explicitly warrant that deleting and recreating any encrypted datasets is necessary.

From: https://zfsonlinux.org/msg/ZFS-8000-ER/

Import the pool and enable the bookmark_v2 feature. Then backup any existing encrypted datasets to new datasets. This can be done with traditional tools or via zfs send. Raw sends will require that the zfs_disable_ivset_guid_check is set to 1 on the receive side. Once this is done, the original datasets should be destroyed.

If I understand that correctly, that could be reworded and the recommend action could be changed from "backup and recreate all encrypted datasets" to delete all snapshots on that pool that where created before the boookmark_v2 feature was enabled? Quite a difference for a lot of admins.

[mtippmann]

@JMoVS thanks for your PR - I'll close this here as the issue is resolved from my perspective.