[Rpm-maint] [rpm-software-management/rpm] RPM with Copy on Write (#1470)

Colin Walters notifications at github.com
Tue Jun 8 14:55:09 UTC 2021


Big picture I'd summarize this as: You're proposing a big alternative way to handle RPMs that only works on reflink-enabled filesystems.

But the basic fact is that there's widespread use of non-reflink filesystems (ext4, older xfs) on Linux in general.  Even if this code was 100% complete and tested, we'd still have to support the non-reflink case for *years* to come for in-place upgrade support at the least.  

Don't get me wrong, I'd love to push towards a state were we can try to hard require reflinks in e.g. Fedora derivatives and make system software that just fails without it.   And require people using older versions to reprovision with a newer filesystem.  But it's hard to underestimate the disruption from that - the benefit has to be really large.

As I've said before in rpm-ostree we already carry a re-implementation of various chunks of librpm as part of the transactional/anti-hysteresis model.  The concept of carrying "pristine" RPMs has been implemented from the start by importing RPMs into ostree commits, then using plain old hardlinks.  For `apply-live` updates, that also inherently implements the "unpack all files, rename() into place" model.

This would be a 3rd new thing with a new mix of tradeoffs.   Which isn't inherently bad, just noting.

Certainly for example, we'd need a way to *force off* reflink support so that the "traditional" path could be tested too.  If this ends up as an optional plugin, then that simplifes that aspect because then e.g. Anaconda could only install it if it detected the target filesystem chosen by the user supported reflinks.

Anyways beyond that high level, on the details of the code I don't have much to add beyond what the librpm maintainers have.  I hope we can figure out how to share more code between these 3 approaches (traditional librpm path, rpm-ostree, RPMCoW).  


-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/1470#issuecomment-856839607
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rpm.org/pipermail/rpm-maint/attachments/20210608/d5fe30f8/attachment.html>


More information about the Rpm-maint mailing list