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.) _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
