[pbs-devel] [RFC proxmox-backup 0/3] Encode creation parameters into pxar archive

[Thomas Lamprecht]

Am 06/03/2024 um 16:13 schrieb Christian Ebner:
>> On 06.03.2024 15:34 CET Gabriel Goller <g.goller at proxmox.com> wrote:
>>
>>  
>> To better debug the creation of the pxar archive, we encode the 
>> creation_params (the parameters passed to the cli) inside the pxar
>> archive. Like this we just need to locate the `.pxar_creation_params`
>> file in the archive and we can check which arguments have been used. 
>>
>> To realize this, we unify all the parameters of the `create_backup`
>> function so that we don't need an additional struct (which in turn
>> introduces additional maintenance efforts).
>>
>> An example `.pxar_creation_params` file would look like this:
>>
>>     {
>>       "backupspec": [
>>         "test.pxar:linux"
>>       ],
>>       "chunk-size": 4096,
>>       "exclude": [
>>         "MAINTAINERS"
>>       ],
>>       "skip-e2big-xattr": true
>>     }
>>
> 
> 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.
> 
> 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?

+1 – I do not like mixing it external (meta) data that has nothing to
do with the actual user data being backed up inside the archive.

> 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.

Yes, if we need to bump that for your stuff it would be worth adding
above too (and maybe some more general way to extend metadata info for
the future without new version bumps required).
Otherwise, I'd rather just do not add it at all for now as just bumping
for this seems a bit overkill and as said, inside the archive is the
wrong place.