On Mon, Dec 21, 2020, at 1:07 PM, Neal Gompa wrote:
Sure, this makes some degree of sense, but it doesn't reduce the IOPS
for actually *doing* the installation.
Yes it does. It avoids writing the compressed data and then copying it back out
uncompressed, which is the same amount of savings as the reflink approach.
(It's also equally incompatible with deltarpm)
This is also a flaw with RPM-OSTree, since you have to fetch
everything individually
No - static deltas exist, plus layered RPMs work on the wire the same. But this isn't
really relevant here.
and construct the root by shifting hardlinks
or reflinks around.
Adding a hardlink indeed requires updating inodes proportional to the number of files, but
that's more an implementation of the transactional update approach, not of the
"download and unpack in parallel" part which is more what we're discussing
here. (Though they are entangled a bit)
Anyways, I'd still stand by my summary that the much lower tech "files in
temporary directory that get rename()d" approach would be all of *more* efficient on
disk, simpler to implement and much less disruptive than an RPM format change. (The main
cost would be a new temporary directory path that would need cleanup as part of e.g. `yum
clean` etc.)