From mboxrd@z Thu Jan 1 00:00:00 1970
Return-Path: <f.ebner@proxmox.com>
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))
(No client certificate requested)
by lists.proxmox.com (Postfix) with ESMTPS id 8809F72EEA
for <pve-devel@lists.proxmox.com>; Mon, 5 Jul 2021 09:59:04 +0200 (CEST)
Received: from firstgate.proxmox.com (localhost [127.0.0.1])
by firstgate.proxmox.com (Proxmox) with ESMTP id 784031BE3B
for <pve-devel@lists.proxmox.com>; Mon, 5 Jul 2021 09:59:04 +0200 (CEST)
Received: from proxmox-new.maurer-it.com (proxmox-new.maurer-it.com
[94.136.29.106])
(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
key-exchange X25519 server-signature RSA-PSS (2048 bits))
(No client certificate requested)
by firstgate.proxmox.com (Proxmox) with ESMTPS id D64F31BE30
for <pve-devel@lists.proxmox.com>; Mon, 5 Jul 2021 09:59:03 +0200 (CEST)
Received: from proxmox-new.maurer-it.com (localhost.localdomain [127.0.0.1])
by proxmox-new.maurer-it.com (Proxmox) with ESMTP id A46FD40BC3
for <pve-devel@lists.proxmox.com>; Mon, 5 Jul 2021 09:59:03 +0200 (CEST)
To: Aaron Lauterer <a.lauterer@proxmox.com>, pve-devel@lists.proxmox.com
References: <20210601161025.32024-1-a.lauterer@proxmox.com>
<20210601161025.32024-2-a.lauterer@proxmox.com>
<1e42feae-5362-1efb-a8d2-5ee425f17d67@proxmox.com>
<7bc5f848-8891-0b1f-39c1-4eab330907cd@proxmox.com>
From: Fabian Ebner <f.ebner@proxmox.com>
Message-ID: <b71382f6-ddf2-0c84-3e22-23b0ad4d46d1@proxmox.com>
Date: Mon, 5 Jul 2021 09:58:46 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101
Thunderbird/78.11.0
MIME-Version: 1.0
In-Reply-To: <7bc5f848-8891-0b1f-39c1-4eab330907cd@proxmox.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
X-SPAM-LEVEL: Spam detection results: 0
AWL 0.588 Adjusted score from AWL reputation of From: address
BAYES_00 -1.9 Bayes spam probability is 0 to 1%
KAM_DMARC_STATUS 0.01 Test Rule for DKIM or SPF Failure with Strict Alignment
NICE_REPLY_A -0.001 Looks like a legit reply (A)
SPF_HELO_NONE 0.001 SPF: HELO does not publish an SPF Record
SPF_PASS -0.001 SPF: sender matches SPF record
Subject: Re: [pve-devel] [RFC storage 1/7] storage: expose find_free_diskname
X-BeenThere: pve-devel@lists.proxmox.com
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Proxmox VE development discussion <pve-devel.lists.proxmox.com>
List-Unsubscribe: <https://lists.proxmox.com/cgi-bin/mailman/options/pve-devel>,
<mailto:pve-devel-request@lists.proxmox.com?subject=unsubscribe>
List-Archive: <http://lists.proxmox.com/pipermail/pve-devel/>
List-Post: <mailto:pve-devel@lists.proxmox.com>
List-Help: <mailto:pve-devel-request@lists.proxmox.com?subject=help>
List-Subscribe: <https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel>,
<mailto:pve-devel-request@lists.proxmox.com?subject=subscribe>
X-List-Received-Date: Mon, 05 Jul 2021 07:59:04 -0000
Am 02.07.21 um 15:38 schrieb Aaron Lauterer:
>
>
> On 6/2/21 10:29 AM, Fabian Ebner wrote:
>> Am 01.06.21 um 18:10 schrieb Aaron Lauterer:
>>> Signed-off-by: Aaron Lauterer <a.lauterer@proxmox.com>
>>> ---
>>> PVE/Storage.pm | 8 ++++++++
>>> 1 file changed, 8 insertions(+)
>>>
>>> diff --git a/PVE/Storage.pm b/PVE/Storage.pm
>>> index aa36bad..93d09ce 100755
>>> --- a/PVE/Storage.pm
>>> +++ b/PVE/Storage.pm
>>> @@ -201,6 +201,14 @@ sub storage_can_replicate {
>>> return $plugin->storage_can_replicate($scfg, $storeid, $format);
>>> }
>>> +sub find_free_diskname {
>>> + my ($cfg, $storeid, $vmid, $fmt, $add_fmt_suffix) = @_;
>>
>> Nit: Ideally, the $add_fmt_suffix should be decided by the plugin, as
>> an outside caller cannot know what a plugin wants/expects. Don't know
>> if that's easy to do the way things are though.
>
> Yeah, I am not sure how to handle that... most of our storage plugins
> don't use it at all (ZFS, RBD, LVM). That leaves the Plugin.pm (storage
> based) and potential 3rd party plugins that have their own implementation.
> Depending on where you would use the now public `find_free_diskname`, it
> could be possible to know the format and if the suffix should already be
> added. For the move-disk to other guest (disk reassign) stuff I cannot
> do that and leave it undefined.
>
The problem is that half of the plugins will quietly ignore the
parameter and the other half (dir based plugins) will return a disk name
they cannot even handle when add_fmt_suffix=0. I'd rather avoid such a
surprising interface.
The same criticism applies to the plugin's interface, but at least there
the calls come from the plugins themselves, which know what they need/want.
Two potential solutions:
1) Remove the add_fmt_suffix parameter from the plugin's
find_free_diskname and either:
a) add custom implementations to the non-dir-based plugins, never adding
the suffix.
b) adapt the generic implementation to add the suffix depending on
whether $scfg->{path} is present or not.
2) Add a new function to the plugin interface, returning whether the
plugin expects a suffix to be added or not, and use that in this patch's
proposed find_free_diskname.
IMHO 1) is much cleaner, but also a breaking change to the plugin API.
But currently APIAGE is 0, so it wouldn't be as bad.
> In the Plugin.pm implementation of `rename_volume` I added a check if a
> suffix is present, and if not, take the one from the source volume.
> Thinking about it, I might even strip any potential suffixes and always
> use the one from the source as that should be kept since the file format
> probably should not change with a rename.
>
>>
>>> +
>>> + my $scfg = storage_config($cfg, $storeid);
>>> + my $plugin = PVE::Storage::Plugin->lookup($scfg->{type});
>>> + return $plugin->find_free_diskname($storeid, $scfg, $vmid, $fmt,
>>> $add_fmt_suffix);
>>> +}
>>> +
>>> sub storage_ids {
>>> my ($cfg) = @_;
>>>