From mboxrd@z Thu Jan 1 00:00:00 1970
Return-Path: <t.lamprecht@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 514ED622B7
for <pbs-devel@lists.proxmox.com>; Mon, 21 Feb 2022 14:39:05 +0100 (CET)
Received: from firstgate.proxmox.com (localhost [127.0.0.1])
by firstgate.proxmox.com (Proxmox) with ESMTP id 47D321974A
for <pbs-devel@lists.proxmox.com>; Mon, 21 Feb 2022 14:39:05 +0100 (CET)
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 B4B5F19741
for <pbs-devel@lists.proxmox.com>; Mon, 21 Feb 2022 14:39:04 +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 8670945239
for <pbs-devel@lists.proxmox.com>; Mon, 21 Feb 2022 14:39:04 +0100 (CET)
Message-ID: <05266c31-3897-aed9-abe8-69ec07e84e44@proxmox.com>
Date: Mon, 21 Feb 2022 14:39:03 +0100
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:98.0) Gecko/20100101
Thunderbird/98.0
Content-Language: en-US
To: Proxmox Backup Server development discussion
<pbs-devel@lists.proxmox.com>, Dominik Csapak <d.csapak@proxmox.com>,
Dylan Whyte <d.whyte@proxmox.com>
References: <20220126153836.2053113-1-d.whyte@proxmox.com>
<4dec537e-4526-0db7-bb06-bf25a3c04ddb@proxmox.com>
From: Thomas Lamprecht <t.lamprecht@proxmox.com>
In-Reply-To: <4dec537e-4526-0db7-bb06-bf25a3c04ddb@proxmox.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
X-SPAM-LEVEL: Spam detection results: 0
AWL 0.058 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
T_SCC_BODY_TEXT_LINE -0.01 -
Subject: Re: [pbs-devel] [PATCH V2 proxmox-backup] Fix 3335: Allow removing
datastore contents on delete
X-BeenThere: pbs-devel@lists.proxmox.com
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Proxmox Backup Server development discussion
<pbs-devel.lists.proxmox.com>
List-Unsubscribe: <https://lists.proxmox.com/cgi-bin/mailman/options/pbs-devel>,
<mailto:pbs-devel-request@lists.proxmox.com?subject=unsubscribe>
List-Archive: <http://lists.proxmox.com/pipermail/pbs-devel/>
List-Post: <mailto:pbs-devel@lists.proxmox.com>
List-Help: <mailto:pbs-devel-request@lists.proxmox.com?subject=help>
List-Subscribe: <https://lists.proxmox.com/cgi-bin/mailman/listinfo/pbs-devel>,
<mailto:pbs-devel-request@lists.proxmox.com?subject=subscribe>
X-List-Received-Date: Mon, 21 Feb 2022 13:39:05 -0000
On 21.02.22 12:10, Dominik Csapak wrote:
> while=C2=A0i=C2=A0know=C2=A0that=C2=A0we=C2=A0don't=C2=A0recommend=C2=A0=
having=C2=A0other=C2=A0data=C2=A0in=C2=A0the=C2=A0datastore,
> imho=C2=A0it's=C2=A0not=C2=A0wise=C2=A0to=C2=A0remove=C2=A0*everything*=
=C2=A0in=C2=A0the=C2=A0datastore=C2=A0path
>=20
> AFAICT=C2=A0we=C2=A0can=C2=A0know=C2=A0what=C2=A0we=C2=A0touch=C2=A0(ct=
/host/vm/.chunk=C2=A0dirs,=C2=A0.gc-status,=C2=A0.lock)
> so=C2=A0we=C2=A0could=C2=A0only=C2=A0remove=C2=A0that?
>=20
meh, I'm torn a bit; While PBS owns the datastore directory and this
is really fine to do IMO, it'd be relatively simple to avoid doing, as
like you say, there are few and always known top-level directories we nee=
d
to iterate over; if empty I'd also delete the top-level directory itself
though.
> also=C2=A0we=C2=A0should=C2=A0probably=C2=A0remove=C2=A0the=C2=A0datast=
ore=C2=A0from=C2=A0the=C2=A0config=C2=A0before
> removing=C2=A0files=C2=A0from=C2=A0it?=C2=A0otherwise=C2=A0i=C2=A0can=C2=
=A0start=C2=A0deleting
> and=C2=A0another=C2=A0user=C2=A0could=C2=A0start=C2=A0his=C2=A0backup=C2=
=A0which=C2=A0will
> interfere=C2=A0with=C2=A0each=C2=A0other=C2=A0and=C2=A0leave=C2=A0the=C2=
=A0datastore=C2=A0in=C2=A0an
> undefined=C2=A0state?
it should be put in maintenance state prior to starting off deletion,
that handles this already nicely and can set a readable info message; onc=
e
it's finally applied that is.
>=20
> what=C2=A0we=C2=A0at=C2=A0least=C2=A0should=C2=A0have=C2=A0here=C2=A0is=
=C2=A0some=C2=A0mechanism=C2=A0that=C2=A0nobody
> can=C2=A0backup/restore/etc.=C2=A0from=C2=A0a=C2=A0datastore=C2=A0while=
=C2=A0it's=C2=A0deleted
see above
>> + let info =3D &api2::config::datastore::API_METHOD_DELETE_DATASTOR=
E;
>> + let result =3D match info.handler {
>> + ApiHandler::Async(handler) =3D> (handler)(param, info, rpcenv=
).await?,
>> + _ =3D> unreachable!(),
>> + };
>> +
>> + crate::wait_for_local_worker(result.as_str().unwrap()).await?;
>> + Ok(Value::Null)
>> +
>=20
> i know the other functions in this file do it exactly like this,
> but i'd probably prefer to have a http client here to
> do the deletion via the api? (like we do in most other cases)
hmm, while I agree in general for most commands I'm not so sure about thi=
s
specific one; this is something a admin may need to do when no space is l=
eft
anymore, having less parts involved could make it more robust in some cas=
es.