public inbox for pbs-devel@lists.proxmox.com
 help / color / mirror / Atom feed
From: "Gabriel Goller" <g.goller@proxmox.com>
To: "Christian Ebner" <c.ebner@proxmox.com>,
	"Proxmox Backup Server development discussion"
	<pbs-devel@lists.proxmox.com>
Subject: Re: [pbs-devel] [RFC proxmox-backup 0/3] Encode creation parameters into pxar archive
Date: Thu, 07 Mar 2024 10:22:49 +0100	[thread overview]
Message-ID: <CZNEPKLCOFTE.2T7529VVKOCPF@proxmox.com> (raw)
In-Reply-To: <1800721063.9375.1709738015138@webmail.proxmox.com>

Thanks for the review!

On Wed Mar 6, 2024 at 4:13 PM CET, Christian Ebner wrote:
> Wouldn't it make sense to extend the pxar file format by a dedicated
> entry type to store such information? And handle these entries in a
> dedicated manner? E.g. by a `PXAR_CLI_PARAMS` entry header?

I though about this but disregarded it ultimately because of the whole 
version update and backwards compat hassle. IMO this is 'debug data' 
and 'extra information' so it would fit better inside the archive (same
as the exclude-patterns, these are also not really important after the 
archive has been created (except for debugging)). If for some reason 
this data is missing it wouldn't be a problem at all.

> While this approach has already been used up until now for storing the
> pxar cli exclude patterns, allowing to encode such metadata inside the
> archive as regular file without having any means other than the filename
> to find and distinguish this information from other files seems not
> ideal to me.

We could also specify some kind of prefix for pxar-specific files,
something like '.pxar_***'? This way we stay consistent and users can
distinguish manually encoded files from their files.
But I also get your point about having regular files appear in the pxar
archive could be confusing to some. And obviously having 3+ of these
files is a no-go.

> This would of course require an updated pxar format version 2, which we
> might need anyways if the patches regarding metadata based change
> detection should be applied.

Although this is a good point, if we merge both series in the same
window, we would only have to do one update! 


For some reason—now that I am writing this obviously—I am currently more
inclined to your version. Mostly because the `.pxarexclude` file also
allows input (e.g. the user can create the file insert stuff), while 
the `.pxar_creation_params` does not allow input and would have to 
overwrite/ignore an existing file.

I am open to other suggestions/inputs!




  reply	other threads:[~2024-03-07  9:22 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-03-06 14:34 Gabriel Goller
2024-03-06 14:34 ` [pbs-devel] [PATCH proxmox-backup 1/3] pxar: factor out encode_file Gabriel Goller
2024-03-06 14:34 ` [pbs-devel] [PATCH proxmox-backup 2/3] client: unify parameters and write to file Gabriel Goller
2024-03-06 14:34 ` [pbs-devel] [PATCH proxmox-backup 3/3] pxar: added creation parameters Gabriel Goller
2024-03-06 15:13 ` [pbs-devel] [RFC proxmox-backup 0/3] Encode creation parameters into pxar archive Christian Ebner
2024-03-07  9:22   ` Gabriel Goller [this message]
2024-03-07  9:50   ` Thomas Lamprecht

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CZNEPKLCOFTE.2T7529VVKOCPF@proxmox.com \
    --to=g.goller@proxmox.com \
    --cc=c.ebner@proxmox.com \
    --cc=pbs-devel@lists.proxmox.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
Service provided by Proxmox Server Solutions GmbH | Privacy | Legal