[Rpm-maint] [rpm-software-management/rpm] Add FA_REFLINK file action (PR #2557)

Panu Matilainen notifications at github.com
Mon Jul 3 08:24:56 UTC 2023


Thanks for working on this. Some birds-eye comments on the approach:

- We can't expose a linux-specific struct in the API like that. Need to find a way to abstract that out one way or the other, passing void pointers around is one possibility. Or limit the reflink to whole fd's in the API which would look much simpler and nicer from rpm POV (but I realize, is at odds with the link-from-the-rpm-payload approach, but then that is at odds with rpm itself to begin with)
- Storing the clone info in rpmfi struct seems problematic: there can be thousands of files in a package, we can't have open fd's to them all. So the API probably needs to reflect that, basically "pass me an fd" style rather than set/get something in the fi. 
- The fallback case should use the same code as the regular FA_CREATE to the extent possible. Some refactoring may be needed... Basically I think FA_REFLINK is a simple case that should probably happen inside fsm.c and then fallback to the normal code otherwise. I realize it's written the way it is to faciliate reflink from the rpm file directly but as said, that's at odds with rpm itself at a pretty fundamental level and I'm not convinced we're willing to go there. Unless people start compressing entire rpms instead of just the payload, but that probably runs into different issues.

-- 
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2557#issuecomment-1617610985
You are receiving this because you are subscribed to this thread.

Message ID: <rpm-software-management/rpm/pull/2557/c1617610985 at github.com>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rpm.org/pipermail/rpm-maint/attachments/20230703/dbd46e0c/attachment.html>


More information about the Rpm-maint mailing list