[Rpm-maint] [rpm-software-management/rpm] API improvement to accommodate for RPM CoW (PR#1470) (Discussion #2057)
malmond77
notifications at github.com
Wed Dec 7 00:13:26 UTC 2022
The idea of aligning cpio metadata is very interesting. I can see how it'd help initramfs building speed tremendously.
As I understand it, RPM is pretty different: the main difference is that we're trying (fairly hard) not to change the normal format of rpm as found on mirrors for now. There are some very interesting ideas on how to change the upstream format, but in doing so, we'd render all existing servers unable to read the format.
If we could tolerate the breakage: I'd love to experiment with `BTRFS_IOC_ENCODED_WRITE` which would reduce writes down and eliminate explicit decompression. For clients or filesystems without CoW support: RPM could decompress and write the normal file. I was hoping encoded writes would eliminate the complex path with curl -> librepo -> rpm2extents. I'm not sure you could get data from the network and write encoded data to disk in one pass like we're doing now. Do you have any ideas on how to resolve that challenge?
Adding cpio metadata, along with a "null" compression type could help eliminate the change in `fsm.c` on how the payload is iterated. Note that `rpm2extents` does not (and cannot) touch headers without invalidating signatures, so the change in compression type is inferred and handled in the plugin.
Lastly, there's another optimization that would be lost in adopting cpio formatting: content de-duplication. I'm not sure how important this is tho in the big picture, so it might be a worthwhile tradeoff.
Thanks for the feedback! Matthew.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/discussions/2057#discussioncomment-4328192
You are receiving this because you are subscribed to this thread.
Message ID: <rpm-software-management/rpm/repo-discussions/2057/comments/4328192 at github.com>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rpm.org/pipermail/rpm-maint/attachments/20221206/704054e8/attachment.html>
More information about the Rpm-maint
mailing list