From mboxrd@z Thu Jan 1 00:00:00 1970
Return-Path: <pve-devel-bounces@lists.proxmox.com>
Received: from firstgate.proxmox.com (firstgate.proxmox.com [212.224.123.68])
by lore.proxmox.com (Postfix) with ESMTPS id 143DD1FF16E
for <inbox@lore.proxmox.com>; Mon, 14 Apr 2025 16:35:39 +0200 (CEST)
Received: from firstgate.proxmox.com (localhost [127.0.0.1])
by firstgate.proxmox.com (Proxmox) with ESMTP id A8C6535FDF;
Mon, 14 Apr 2025 16:35:36 +0200 (CEST)
Date: Mon, 14 Apr 2025 16:35:33 +0200
From: Wolfgang Bumiller <w.bumiller@proxmox.com>
To: Fiona Ebner <f.ebner@proxmox.com>
Message-ID: <hc6g2n3dw4hqmidefnlsnmmmrpqqbmf5ocy2jilgv4hlas3yan@bsru6bmxlzu6>
References: <20250326142059.261938-1-m.carrara@proxmox.com>
<20250326142059.261938-9-m.carrara@proxmox.com>
<1743495535.spdhir37c5.astroid@yuna.none>
<09a25015-f84c-4670-aad4-2ce3956189ad@proxmox.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <09a25015-f84c-4670-aad4-2ce3956189ad@proxmox.com>
X-SPAM-LEVEL: Spam detection results: 0
AWL 0.082 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
Subject: Re: [pve-devel] [PATCH v1 pve-storage 8/8] pluginbase: document
import and export methods
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>
Reply-To: Proxmox VE development discussion <pve-devel@lists.proxmox.com>
Cc: Proxmox VE development discussion <pve-devel@lists.proxmox.com>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Errors-To: pve-devel-bounces@lists.proxmox.com
Sender: "pve-devel" <pve-devel-bounces@lists.proxmox.com>
On Tue, Apr 01, 2025 at 11:40:14AM +0200, Fiona Ebner wrote:
> Am 01.04.25 um 10:40 schrieb Fabian Gr=FCnbichler:
> > On March 26, 2025 3:20 pm, Max Carrara wrote:
> >> +=3Dhead3 $plugin->volume_export(\%scfg, $storeid, $fh, $volname, $for=
mat [, $snapshot, $base_snapshot, $with_snapshots])
> >> +
> >> +=3Dhead3 $plugin->volume_export(...)
> >> +
> >> +Exports a volume or a volume's C<$snapshot> into a file handle C<$fh>=
as a
> >> +stream with a desired export C<$format>. See L<FORMATS> for all impor=
t/export
> >> +formats.
> >> +
> >> +Optionally, C<$snapshot> (if provided) may have a C<$base_snapshot>, =
and
> >> +C<$with_snapshots> states whether the volume has snapshots overall.
> > =
> > this is incomplete/wrong
> > =
> > $with_snapshots means the export should include snapshots, not whether
> > the volume has snapshots..
> > $snapshot means "this is the snapshot to export" if only exporting the
> > snapshot ($with_snapshots =3D=3D 0), or "this is the *last* snapshot ex=
port"
> > if exporting a stream of snapshots ($with_snapshots =3D=3D 1)
> > $base_snapshot means "this is the start of the snapshot range to export"
> > (i.e., do an incremental export on top of this base)
> > =
> > this is mostly only relevant for zfs at the moment (other storages can
> > either export a volume including its snapshots, or just the volume, but
> > no complicated incremental streams of snapshots), but will change once
> > we implement replication export/import for other storages..
> =
> There are already ideas floating around to change this and add proper
> format negotiation. We'll also need to ask the target what it supports
> like for remote migration, the sending side cannot really know that. And
> as part of that change from the confusing set of snapshot-related
> parameters to having an actual "what kind of transport" enum:
> 1. current data (of an image or a snapshot)
> 2. full sync with all snapshots
> 3. incremental stream
> No details worked out yet though and not really relevant for documenting
> the status quo.
> =
> >> +Optionally, C<$snapshot> (if provided) may have a C<$base_snapshot>, =
and
> >> +C<$with_snapshots> states whether the volume has snapshots overall. R=
enaming an
> >> +existing volume may also optionally be allowed via C<$allow_rename>
> > =
> > see above, but here $snapshot is mainly there to have the same
> > arguments for volume_import_formats so a plugin can have a single
> > implementation, not because it is used anywhere IIRC..
> =
> The LVMPlugin.pm and Plugin.pm do have different implementations of the
> volume_{export,import}_formats() methods, precisely because they need to
> ignore the $snapshot parameter for the import case. Yes, we do pass the
> same arguments, but it can only matter for the "incremental stream"
> scenario. Otherwise, the parameter has nothing to do with the import
> side. Here it would also be much nicer to have an actual "what kind of
> transport" parameter.
Actually, 'btrfs' format for btrfs-send/recv uses the snapshot name in
both import & export cases:
- We receive into a temporary directory
- BTRFS does not allow moving read-only snapshots into different
directories, but we need the final one to also be the current writable
state, so:
- We remove the read-only flag.
- We exchange it with the current sate.
- We take a "snapshot" to reproduce the that last `$snapshot`.
- We clean up.
It's a bit awkward. But that's just BTRFS...
_______________________________________________
pve-devel mailing list
pve-devel@lists.proxmox.com
https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel