]> git.proxmox.com Git - pve-storage.git/commit
zfs: list: only cache and list images for requested storage/pool
authorFiona Ebner <f.ebner@proxmox.com>
Tue, 20 Dec 2022 13:16:36 +0000 (14:16 +0100)
committerFabian Grünbichler <f.gruenbichler@proxmox.com>
Wed, 21 Dec 2022 09:46:15 +0000 (10:46 +0100)
commitc2e6a90d4f4c635d18d1f88f8abdddb83d8b402d
tree3fa12ab4015d363fc94424e47dc6b77d8e2759fb
parent4be012a4cd623fee74292128df924a4e9f38238b
zfs: list: only cache and list images for requested storage/pool

The plugin for remote ZFS storages currently also uses the same
list_images() as the plugin for local ZFS storages. There is only
one cache which does not remember the target host where the
information originated.

This is problematic for rescan in qemu-server:
1. Via list_images() and zfs_list_zvol(), ZFSPlugin.pm's zfs_request()
   is executed for a remote ZFS.
2. $cache->{zfs} is set to the result of scanning the images there.
3. Another list_images() for a local ZFS storage happens and uses the
   cache with the wrong information.

The only two operations using the cache currently are
1. Disk rescan in qemu-server which is affected by the issue. It is
   done as part of (or as a) long-running operations.
2. prepare_local_job for pvesr, but the non-local ZFS plugin doesn't
   support replication, so it cannot trigger there. The cache only
   helps if there is a replicated guest with volumes on different
   ZFS storages, but otherwise it will be less efficient than no
   cache or querying every storage by itself.

Fix the issue by making the cache $storeid-specific, which effectively
makes the cache superfluous, because there is no caller using the same
$storeid multiple times. As argued above, this should not really hurt
the callers described above much and actually improves performance for
all other callers.

Signed-off-by: Fiona Ebner <f.ebner@proxmox.com>
PVE/Storage/ZFSPoolPlugin.pm