[Rpm-maint] [rpm-software-management/rpm] API improvement to accommodate for RPM CoW (PR#1470) (Discussion #2057)

[David Disseldorp]

Thanks for working on this - the new CoW extent based approach looks exciting. I have a few comments / questions on the initial proposal...

> Files are converted (“transcoded”) locally during download using /usr/bin/rpm2extents (part of rpm codebase). The format is not intended to be “portable” - i.e. copying the files from the cache is not supported.
>
> Regular RPMs use a compressed .cpio based payload. In contrast, extent based RPMs contain uncompressed data aligned to the fundamental page size of the architecture, e.g. 4KiB on x86_64. This alignment is required for FICLONERANGE to work. Only files are represented in the payload, other directory entries like symlinks, device nodes etc are constructed entirely from rpm header information. Files are referenced by their digest, so identical files are de-duplicated.

I just wanted to highlight that, although not optimal, cpio archives can still be used alongside reflinks if the `newc` spec is *bent* a little to provide file data-segment alignment. The kernel initramfs archive format is quite static, so for [dracut-cpio](https://github.com/dracutdevs/dracut/pull/1531) (`dracut --enhanced-cpio`) reflinks I added functionality to zero-pad file names so that subsequent file data segments are block aligned. kernel and GNU cpio extractors handle this fine, with the caveat that padding can't exceed `PATH_MAX`.

On a separate note, Btrfs recently gained support for writing compressed extents directly to disk via the new `BTRFS_IOC_ENCODED_WRITE` ioctl. IIUC, Fedora also recently changed to using zstd by default for Btrfs root and rpms. Have you considered using `BTRFS_IOC_ENCODED_WRITE` functionality instead of performing decompression during download?

-- 
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/discussions/2057#discussioncomment-4327609
You are receiving this because you are subscribed to this thread.

Message ID: <rpm-software-management/rpm/repo-discussions/2057/comments/4327609 at github.com>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rpm.org/pipermail/rpm-maint/attachments/20221206/f1ab947e/attachment-0001.html>