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

[Colin Walters]

I referenced this effort in https://marc.info/?l=linux-fsdevel&m=167794198604510&w=2 - my PoV is that the rpm-cow effort makes some sense.  I thought a lot though about hard requiring reflinks for ostree though and determined it was not viable.  There are too many people that use e.g. ext4.  And even if we stopped supporting new installs with that, IMO we need to support in-place upgrades for rpm systems deployed w/ext4 (or xfs without `-m reflink=1`) for a (really) long time.  

On the ostree side I thought about hard requiring reflinks and just concluded it was not viable to have two different code paths.

What ultimately I think will work better here is using overlay-style filesystems.  From my PoV composefs or something similar is the successor to ostree.  And that type of overlayfs style approach Just Works even on non-reflink filesystems (albeit less efficiently sometimes).  So there's no concerns with in-place upgrades, and that's ultimately why I think it's a more viable approach for both bootable host systems and containers.  (Now, how exactly one would try to tie something composefs-like into something that feels more traditional-rpm like is a bit more of an open question; would a higher level tool like yum/zypper end up making composefs snapshots locally, etc?  We'll be doing this for rpm-ostree at least, but it was designed from the start for that)

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

Message ID: <rpm-software-management/rpm/pull/2378/c1458653493 at github.com>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rpm.org/pipermail/rpm-maint/attachments/20230307/38c04827/attachment.html>