[pve-devel] [PATCH pve-storage v2] fix #6561: zfspool: track refquota for subvolumes via user properties

Shannon Sterz s.sterz at proxmox.com
Tue Jul 29 11:41:14 CEST 2025


zfs itself does not track the refquota per snapshot so we need handle
this ourselves. otherwise rolling back a volume that has been resize
since the snapshot, will retain the new size. this is problematic, as
it means the value in the guest config does not longer match the size
of the disk on the storage.

this implementation tries to do so by leveraging a user property per
snapshot.

Reported-by: Lukas Wagner <l.wagner at proxmox.com>
Suggested-by: Fabian Grünbichler <f.gruenbichler at proxmox.com>
Signed-off-by: Shannon Sterz <s.sterz at proxmox.com>
---
 src/PVE/Storage/ZFSPoolPlugin.pm | 44 +++++++++++++++++++++++++++++++-
 1 file changed, 43 insertions(+), 1 deletion(-)

diff --git a/src/PVE/Storage/ZFSPoolPlugin.pm b/src/PVE/Storage/ZFSPoolPlugin.pm
index cdf5868..d329abc 100644
--- a/src/PVE/Storage/ZFSPoolPlugin.pm
+++ b/src/PVE/Storage/ZFSPoolPlugin.pm
@@ -482,9 +482,28 @@ sub volume_size_info {
 sub volume_snapshot {
     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);
 
     $class->zfs_request($scfg, undef, 'snapshot', "$scfg->{pool}/$vname\@$snap");
+
+    # if this is a subvol, track refquota information via user properties. zfs
+    # does not track this property for snapshosts and consequently does not roll
+    # it back. so track this information manually.
+    if ($format eq 'subvol') {
+        my $refquota = $class->zfs_request(
+            $scfg, undef, 'get', 'refquota', '-o', 'value', '-Hp', "$scfg->{pool}/$vname",
+        );
+
+        chomp($refquota);
+
+        $class->zfs_request(
+            $scfg,
+            undef,
+            'set',
+            "pve-storage:refquota=${refquota}",
+            "$scfg->{pool}/$vname\@$snap",
+        );
+    }
 }
 
 sub volume_snapshot_delete {
@@ -503,6 +522,29 @@ sub volume_snapshot_rollback {
 
     my $msg = $class->zfs_request($scfg, undef, 'rollback', "$scfg->{pool}/$vname\@$snap");
 
+    # if this is a subvol, check if we tracked the refquota manually via user
+    # properties and if so, set it appropriatelly again.
+    if ($format eq 'subvol') {
+        my $refquota = $class->zfs_request(
+            $scfg,
+            undef,
+            'get',
+            'pve-storage:refquota',
+            '-o',
+            'value',
+            '-Hp',
+            "$scfg->{pool}/$vname\@$snap",
+        );
+
+        chomp($refquota);
+
+        if ($refquota =~ m/^\d+$/) {
+            $class->zfs_request(
+                $scfg, undef, 'set', "refquota=${refquota}", "$scfg->{pool}/$vname",
+            );
+        }
+    }
+
     # 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
-- 
2.47.2





More information about the pve-devel mailing list