rpm copies file content in and out of packages with a plain read/write loop in
userspace. I'd like to switch that to copy_file_range() if the kernel provides
it, and wanted to check for interest before submitting a PR.
copy_file_range() does the copy in the kernel, so it's fewer syscalls and the
bytes don't pass through userspace. On filesystems that support it the kernel
can also satisfy the copy without duplicating the data on disk, which is the
interesting part for local image building, where you install the same packages
into many roots on one filesystem and today every file gets copied out in full
each time.
The kernel can only avoid the duplicate when the source content is
block-aligned, and rpm payloads aren't aligned today, so this comes as two
commits.
The first adds an optional aligned payload. With %_payload_alignment set,
regular files at least as big as the alignment start on a block boundary,
recorded in a new RPMTAG_PAYLOADALIGNMENT tag. Smaller files, symlinks and
directories keep the usual 4-byte cpio padding, it works with or without
compression, and readers skip the padding on their own. The payload digest
still covers the padding, so rpm -K and the per-file digests verify as before.
The second uses copy_file_range() for the content copy on build and install,
for uncompressed payloads, when it's available (checked at configure time,
ordinary read/write loop otherwise). It's automatic with no new API, and
installed content is still read back and hashed.
This only helps when you build and install on the same filesystem, not for
pulling compressed packages from a repo. Is switching payload copies to
copy_file_range() something rpm would want?
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/discussions/4265
You are receiving this because you are subscribed to this thread.
Message ID: <rpm-software-management/rpm/repo-discussions/[email protected]>
_______________________________________________
Rpm-maint mailing list
[email protected]
https://lists.rpm.org/mailman/listinfo/rpm-maint
