as described in the zfs bug https://github.com/openzfs/zfs/issues/10931
the kernel keeps around cached data from mmaps after a rollback, thus
having invalid data in files that were allegedly rolled back
to workaround this (until a real fix comes along), we unmount the subvol,
invalidating the kernel cache anyway
the dataset gets mounted on the next 'activate_volume' again
Signed-off-by: Dominik Csapak <d.csa...@proxmox.com>
---
PVE/Storage/ZFSPoolPlugin.pm | 13 +++++++++++--
1 file changed, 11 insertions(+), 2 deletions(-)
diff --git a/PVE/Storage/ZFSPoolPlugin.pm b/PVE/Storage/ZFSPoolPlugin.pm
index 3054331..105d802 100644
--- a/PVE/Storage/ZFSPoolPlugin.pm
+++ b/PVE/Storage/ZFSPoolPlugin.pm
@@ -467,9 +467,18 @@ sub volume_snapshot_delete {
sub volume_snapshot_rollback {
my ($class, $scfg, $storeid, $volname, $snap) = @_;
- my $vname = ($class->parse_volname($volname))[1];
+ my (undef, $vname, undef, undef, undef, undef, $format) =
$class->parse_volname($volname);
+
+ my $msg = $class->zfs_request($scfg, undef, 'rollback',
"$scfg->{pool}/$vname\@$snap");
+
+ # we have to unmount rollbacked subvols, to invalidate wrong kernel
+ # caches, they get mounted in activate volume again
+ # see zfs bug #10931 https://github.com/openzfs/zfs/issues/10931
+ if ($format eq 'subvol') {
+ $class->zfs_request($scfg, undef, 'unmount', "$scfg->{pool}/$vname");
+ }
- $class->zfs_request($scfg, undef, 'rollback',
"$scfg->{pool}/$vname\@$snap");
+ return $msg;
}
sub volume_rollback_is_possible {
--
2.20.1
_______________________________________________
pve-devel mailing list
pve-devel@lists.proxmox.com
https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
