On Tue, Dec 22, 2020 at 12:58 PM Matthew Almond via devel <devel@lists.fedoraproject.org> wrote: > > There is also some confusion between compressed data in the rpm and the > transcoded one, and filesystem level compression. This proposal affects the > former, but not the latter. I'd caution against using btrfs specific > attributes to disable compression the dnf/rpm cache directory tree, because > then the extents written/shared to the installed file locations will also not > be compressed. (this is my interpretation of what I expect to see with > FICLONERANGE ioctl etc: it'd be slower if it honored filesystem level > compression because it'd need to re-write the data.)
It shouldn't need to rewrite the data. ficlonerange offset and length is based on the Btrfs logical address space, and this is uncompressed. That behind the scene it happens to be compressed is a sort of "last mile" detail, similar to where the file is actually located. Btrfs logical address for a file suggests there is exactly one copy of the file and one copy of its metadata, but via chunk tree lookup it may be that this file has two copies (raid1) or it may be located on any one of a number of devices. Yet ficlonerange still works as expected regardless of those details. -- Chris Murphy _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
