From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from firstgate.proxmox.com (firstgate.proxmox.com [212.224.123.68]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by lists.proxmox.com (Postfix) with ESMTPS id 3217663BCF for ; Wed, 23 Dec 2020 15:49:27 +0100 (CET) Received: from firstgate.proxmox.com (localhost [127.0.0.1]) by firstgate.proxmox.com (Proxmox) with ESMTP id 1A50AF72D for ; Wed, 23 Dec 2020 15:48:57 +0100 (CET) Received: from proxmox-new.maurer-it.com (proxmox-new.maurer-it.com [212.186.127.180]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by firstgate.proxmox.com (Proxmox) with ESMTPS id 1481DF71F for ; Wed, 23 Dec 2020 15:48:56 +0100 (CET) Received: from proxmox-new.maurer-it.com (localhost.localdomain [127.0.0.1]) by proxmox-new.maurer-it.com (Proxmox) with ESMTP id C955A4564B for ; Wed, 23 Dec 2020 15:48:55 +0100 (CET) To: Wolfgang Bumiller Cc: pve-devel@lists.proxmox.com References: <20201222121852.15803-1-a.lauterer@proxmox.com> <20201222133909.5b3523yjpdq556di@wobu-vie.proxmox.com> From: Aaron Lauterer Message-ID: Date: Wed, 23 Dec 2020 15:48:54 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.6.0 MIME-Version: 1.0 In-Reply-To: <20201222133909.5b3523yjpdq556di@wobu-vie.proxmox.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-SPAM-LEVEL: Spam detection results: 0 AWL 1.248 Adjusted score from AWL reputation of From: address KAM_DMARC_STATUS 0.01 Test Rule for DKIM or SPF Failure with Strict Alignment NICE_REPLY_A -2.521 Looks like a legit reply (A) RCVD_IN_DNSWL_MED -2.3 Sender listed at https://www.dnswl.org/, medium trust SPF_HELO_NONE 0.001 SPF: HELO does not publish an SPF Record SPF_PASS -0.001 SPF: sender matches SPF record URIBL_BLOCKED 0.001 ADMINISTRATOR NOTICE: The query to URIBL was blocked. See http://wiki.apache.org/spamassassin/DnsBlocklists#dnsbl-block for more information. [dirplugin.pm, proxmox.com] Subject: Re: [pve-devel] [PATCH storage] fix 3214: DirPlugin: die early if mountpoint not mounted X-BeenThere: pve-devel@lists.proxmox.com X-Mailman-Version: 2.1.29 Precedence: list List-Id: Proxmox VE development discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Dec 2020 14:49:27 -0000 On 12/22/20 2:39 PM, Wolfgang Bumiller wrote: > Here our `mkdir` meaning is `create the path to the storage`. > > I'd propose the following: > > Apply neither #3214 patch. Keep the `mkdir` code as it is. Deprecate the > `mkdir` option and split it up into 2 new options: > > `create_path` and `populate_directory` > > It should be harder to confuse those two in the future (plus they can > both be set explicitly simultaneously). sounds good! > > On Tue, Dec 22, 2020 at 01:18:52PM +0100, Aaron Lauterer wrote: >> If the `is_mountpoint` option is enabled, it is sensible to first check >> for the mountpoint before proceeding any further in the storage >> activation. >> >> The old behaviour would create the path to the mountpoint if the `mdkir` >> option wasn't set to false. This resulted in mountpoints further up >> the path to not mount anymore, e.g. nested ZFS datasets. >> >> Signed-off-by: Aaron Lauterer >> --- >> >> There is another patch[0] already for this bug report but it deals with >> a related, but different problem of not creating the internal storage >> directory structure if `mkdir 0` was set. >> >> [0] https://lists.proxmox.com/pipermail/pve-devel/2020-December/046572.html >> >> PVE/Storage/DirPlugin.pm | 10 +++++----- >> 1 file changed, 5 insertions(+), 5 deletions(-) >> >> diff --git a/PVE/Storage/DirPlugin.pm b/PVE/Storage/DirPlugin.pm >> index 2267f11..81aaf2b 100644 >> --- a/PVE/Storage/DirPlugin.pm >> +++ b/PVE/Storage/DirPlugin.pm >> @@ -132,17 +132,17 @@ sub status { >> sub activate_storage { >> my ($class, $storeid, $scfg, $cache) = @_; >> >> - my $path = $scfg->{path}; >> - if (!defined($scfg->{mkdir}) || $scfg->{mkdir}) { >> - mkpath $path; >> - } > > Depending on whether we want to also "fix" the defaults (`mkdir` not > present meaning it is not *used*, rather than it is `on`), the above > should either happen `if !defined($scfg->{create_path})` (not explicitly > using `create_path`), or changed to `if ($scfg->{mkdir})` (which should > generate a warning). AFAIU this sounds like a breaking change and should probably only be done on a major version release. If we actually want to change that. > >> - >> my $mp = parse_is_mountpoint($scfg); >> if (defined($mp) && !path_is_mounted($mp, $cache->{mountdata})) { >> die "unable to activate storage '$storeid' - " . >> "directory is expected to be a mount point but is not mounted: '$mp'\n"; >> } >> > > the `is_mountpoint` check would stay here after `mkdir` handling for > legacy behavior. > and below here is where we'd add the hunk below with > `s/mkdir/populate_directory/`; > > The other patch would do use `populate_directory` if it is explicitly > set, otherwise fall through to the old `mkdir` based code with a > warning that `populate_directory` should be explicitly set in the > config. > > >> + my $path = $scfg->{path}; >> + if (!defined($scfg->{mkdir}) || $scfg->{mkdir}) { >> + mkpath $path; >> + } >> + >> $class->SUPER::activate_storage($storeid, $scfg, $cache); >> } >> >> -- >> 2.20.1