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/4328...@github.com>
_______________________________________________
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint
