From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from firstgate.proxmox.com (firstgate.proxmox.com [IPv6:2a01:7e0:0:424::9]) by lore.proxmox.com (Postfix) with ESMTPS id A056A1FF13C for ; Thu, 25 Jun 2026 18:41:18 +0200 (CEST) Received: from firstgate.proxmox.com (localhost [127.0.0.1]) by firstgate.proxmox.com (Proxmox) with ESMTP id 06CA11D4; Thu, 25 Jun 2026 18:41:17 +0200 (CEST) From: "Max R. Carrara" To: pve-devel@lists.proxmox.com Subject: [PATCH pve-storage 1/9] luncmd: lio: fix various errors by removing caching mechanism Date: Thu, 25 Jun 2026 18:40:53 +0200 Message-ID: <20260625164110.706694-2-m.carrara@proxmox.com> X-Mailer: git-send-email 2.47.3 In-Reply-To: <20260625164110.706694-1-m.carrara@proxmox.com> References: <20260625164110.706694-1-m.carrara@proxmox.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Bm-Milter-Handled: 55990f41-d878-4baa-be0a-ee34c49e34d2 X-Bm-Transport-Timestamp: 1782405668000 X-SPAM-LEVEL: Spam detection results: 0 AWL 0.080 Adjusted score from AWL reputation of From: address BAYES_00 -1.9 Bayes spam probability is 0 to 1% DMARC_MISSING 0.1 Missing DMARC policy KAM_DMARC_STATUS 0.01 Test Rule for DKIM or SPF Failure with Strict Alignment SPF_HELO_NONE 0.001 SPF: HELO does not publish an SPF Record SPF_PASS -0.001 SPF: sender matches SPF record Message-ID-Hash: O5ZARDR57D3RV3P4LEWXF2UT4WTN2MDX X-Message-ID-Hash: O5ZARDR57D3RV3P4LEWXF2UT4WTN2MDX X-MailFrom: m.carrara@proxmox.com X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; loop; banned-address; emergency; member-moderation; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header X-Mailman-Version: 3.3.10 Precedence: list List-Id: Proxmox VE development discussion List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: 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 --- 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