[pbs-devel] [RFC pxar 4/20] fix #3174: metadata: impl fn to calc byte size

[Christian Ebner]

> On 28.09.2023 11:00 CEST Wolfgang Bumiller <w.bumiller at proxmox.com> wrote:
> 
>  
> On Thu, Sep 28, 2023 at 10:07:40AM +0200, Christian Ebner wrote:
> > I was giving this some more thought and are not really convinced that sending
> > this trough an encoder instance, which digests the encoded byte stream and counts
> > the bytes is the right approach here.
> 
> How about moving the logic `encode_metadata` from `Encoder` into
> `Metadata` with an `Option<&mut SeqWrite>` parameter, not a full
> Encoder, and just having the encoding vs counting logic live right next
> to each other depending on whether the writer is Some?
> That should be as cheap as it gets?
>

Hmm, the Metadata should however not be concerned about how it might be encoded in different
contexts. That is something only the encoder should be concerned about.

> > 
> > The purpose of this function is to calculate the bytes, which I can easily skip over
> > *without* having to call any expensive encoding/decoding functionality.
> > I might get around this by simply calling the decoder on the byte stream, than I do
> > not need this at all (if I'm not missing something). Might that be the better approach?
> 
> I'm not sure decoding is that much cheaper than dummy-encoding...
> depending on the data I'd say it could even be more expensive in some
> cases? (rare cases though, only with lots of ACLs/xattrs around I
> suppose...)

Probably so, although the data structures are somewhat simple in this case.

> 
> > 
> > Additionally, and maybe even better, I might get rid of this also by letting the
> > PXAR_APPENDIX_REF offset point to the start of the file payload entry, instead of the
> > file entry as is now, thereby being able to blindly skip over this already to begin with.
> > Although I am not sure if that is the best approach for handling the metadata, which should
> > ideally not be encoded twice, once before the PXAR_APPENDIX_REF and the PXAR_PAYLOAD.
> 
> Not sure why skipping data would encode it twice? Or did you mean to
> imply that previously we pointed to metadata, but when instead pointing
> to the payload we need to instead encode it in the new archive which we
> previously did not need to do?

Yes, I was referring to the latter, having to encode the metadata also in the regular part of the archive
would give the same data twice, once the newly encoded and the same in the appended chunks. Storing this
twice bloats the size unnecessarily.

Which brings me to another point I did not take into consideration so far: How to handle files which metadata
changed but was not checked against. Since the catalog only contains size and mtime, only these are comparable.
But I need the current xattrs, acls ecc... Will have to look up if changing those actually changes the mtime as well.