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