copy_file_range() for reading and writing payload content

[daandemeyer]

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?

[Conan-Kudo]

So this would help with image build tools like kiwi that do the installroot preparation on the host filesystem before wrapping the final tree in an image artifact (disk, ISO, tarball, etc.). And of course it helps with standard Fedora and openSUSE installs too, so it would be a significant improvement for us.

I'd love to see this... But...

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?

Does this mean we would have to have uncompressed packages in the repository? It would be pretty painful to lose zstd compression for Fedora packages.

[daandemeyer]

Does this mean we would have to have uncompressed packages in the repository? It would be pretty painful to lose zstd
compression for Fedora packages.

I definitely don't want to give the impression that I want to encourage disabling compression for distribution packages. Every package that goes over a network connection should still be compressed. Only once downloaded should it be decompressed and aligned to make it amenable to fast copying. But I don't think you necessarily always want to do that. If you're downloading an rpm once to install it once, decompressing it to a separate decompressed rpm file and then installing it is strictly worse than just decompressing it and installing it directly in memory. So I don't think we could ever do that by default for regular distro operation. It's only once an rpm is downloaded once and installed multiple times (image builds) that decompressing it to a separate file starts making sense. But decompressing a compressed rpm is a separate discussion (which I'm also interested in and will open a separate discussion for later), this one is purely about allowing fast copies out of rpms that were never compressed.

[Conan-Kudo]

We probably would want this for Mock caches too, right?

[pmatilai]

I'm not at all opposed to enabling rpm to use CoW technology, if we can find a way that makes sense for rpm. That has been the issue with past versions.

I haven't looked at this in sufficient detail to say much, but at least it does sound more plausible than the past transscode-in-flight from dnf plugin ideas out of the gate. So let me get straight:

Distro packages would (eventually) be built with alignment, but compressed. Repeat-users like image-builders and mock could then do the payload decompression once, and replace the payload it in their cached copy of the rpm (or maybe point rpm to a separate payload file). Because the alignment was taken into account when generating the alt payload digest, rpm would merrily consume the result?

[daandemeyer]

@pmatilai Exactly, that's more or less what I have in my prototype. Because of the alt payload digest it's still considered signed so I would just add an operation to decompress an rpm which we'd expose somewhere and mock/image-builders would make use of that to decompress rpms to either a separate cache directory (or in place I guess in the usual cache directory) and get to reap the benefits.

(If you want I can put up a draft PR which adds the payload alignment tag, or I can put up a draft PR with the entire thing end to end, and of course happy to help with other stuff as well if needed to help free up time for you to look at those)

[pmatilai]

Ack. There could be devils in the details of course, but in that case the principle does sound sane and meaningful to rpm. This is pretty much the kind of scenario the alt-digest was added for in the first place.

I'm off to a vacation after today and wont be back before August so I wont be looking at it anytime soon, and our PR queue is quite the pile, but maybe add pointers to the prototype here?