[PATCH pve-storage 1/9] luncmd: lio: fix various errors by removing caching mechanism

["Max R. Carrara" <m.carrara@proxmox.com>]

When put under stress (such as our testing suite), any ZFS-over-iSCSI
storage using the LIO iSCSI provider will sooner or later end up
having dangling disk images. This is due to the cached remote config
not being updated correctly on LUN creation / deletion.

This also sometimes causes a given storage to report that a virtual
disk already exists when trying to create one, even though it was
previously deleted. Only after ~15 seconds will the cache be
refreshed and creating the disk succeeds.

Note that it is unlikely that anyone will run into these things during
"casual" operation.

Instead of trying hard to get cache invalidation right, remove the
config caching mechanism altogether.

My reasoning behind this is that the average user will most likely not
be bombarding their iSCSI storage with tons of new LUNs / virtual
disks all too frequently -- and even if that is the case, they can
probably afford the bandwidth plus CPU cycles used to transfer and
parse a single JSON file a couple times.

This fixes the plugin from causing things to end up in an inconsistent
state when put under stress.

Signed-off-by: Max R. Carrara <m.carrara@proxmox.com>
---
 src/PVE/Storage/LunCmd/LIO.pm | 48 +++--------------------------------
 1 file changed, 3 insertions(+), 45 deletions(-)

diff --git a/src/PVE/Storage/LunCmd/LIO.pm b/src/PVE/Storage/LunCmd/LIO.pm
index 5a53c14d..8e03652c 100644
--- a/src/PVE/Storage/LunCmd/LIO.pm
+++ b/src/PVE/Storage/LunCmd/LIO.pm
@@ -35,8 +35,6 @@ my @CONFIG_FILES = (
 my $BACKSTORE = '/backstores/block';
 
 my $SETTINGS = undef;
-my $SETTINGS_TIMESTAMP = 0;
-my $SETTINGS_MAXAGE = 15; # in seconds
 
 my @ssh_opts = ('-o', 'BatchMode=yes');
 my @ssh_cmd = ('/usr/bin/ssh', @ssh_opts);
@@ -196,36 +194,6 @@ my $get_backstore_prefix = sub {
     return $pool . '-';
 };
 
-# removes the given lu_name from the local list of luns
-my $free_lu_name = sub {
-    my ($scfg, $lu_name) = @_;
-
-    my $new = [];
-    my $target = $get_target_settings->($scfg);
-    foreach my $lun (@{ $target->{luns} }) {
-        if ($lun->{storage_object} ne "$BACKSTORE/$lu_name") {
-            push @$new, $lun;
-        }
-    }
-
-    $target->{luns} = $new;
-};
-
-# locally registers a new lun
-my $register_lun = sub {
-    my ($scfg, $idx, $volname) = @_;
-
-    my $conf = {
-        index => $idx,
-        storage_object => "$BACKSTORE/$volname",
-        is_new => 1,
-    };
-    my $target = $get_target_settings->($scfg);
-    push @{ $target->{luns} }, $conf;
-
-    return $conf;
-};
-
 # extracts the ZFS volume name from a device path
 my $extract_volname = sub {
     my ($scfg, $lunpath) = @_;
@@ -327,8 +295,6 @@ my $create_lun = sub {
         die "unable to determine new LUN index: $res->{msg}";
     }
 
-    $register_lun->($scfg, $lun_idx, $volname);
-
     # step 3: unfortunately, targetcli doesn't always save changes, no matter
     #         if auto_save_on_exit is true or not. So saving to be safe ...
     $execute_remote_command->($scfg, $timeout, $targetcli, 'saveconfig');
@@ -366,9 +332,6 @@ my $delete_lun = sub {
         # step 3: save to be safe ...
         $execute_remote_command->($scfg, $timeout, $targetcli, 'saveconfig');
 
-        # update internal cache
-        $free_lu_name->($scfg, $volname);
-
         last;
     }
 
@@ -407,15 +370,10 @@ my %lun_cmd_map = (
 sub run_lun_command {
     my ($scfg, $timeout, $method, @params) = @_;
 
-    # fetch configuration from target if we haven't yet or if it is stale
-    my $timediff = time - $SETTINGS_TIMESTAMP;
-    my $target = $get_target_settings->($scfg);
-    if (!$target || $timediff > $SETTINGS_MAXAGE) {
-        $SETTINGS_TIMESTAMP = time;
-        $parser->($scfg);
-    }
-
     die "unknown command '$method'" unless exists $lun_cmd_map{$method};
+
+    $parser->($scfg);
+
     my $msg = $lun_cmd_map{$method}->($scfg, $timeout, $method, @params);
 
     return $msg;
-- 
2.47.3