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