Hello,

I opened a request to anaconda team with a draft patch to use unsquashfs instead of rsync: https://github.com/rhinstaller/anaconda/pull/2292.

That should lower the installation time from Live media.

Adjustments should be made to make this patch work, I was not able to install the image using this patch. Anaconda installer crashes.

Chris,

> Could this be read amplification?

> That's probably mitigated with unsquashfs.

That could be read amplification, it will be mitigated with unsquashfs.

The memory usage should not be a problem: xz (1) manual page, states that 2 MiB of memory required to decompress an archive with 1MiB block size. My previous observations found that the squashfs is currently decompressed in single thread. I welcome additional testing, but I think the memory limit will not be a problem.

> If image size is a significant consideration, then evaluation of erofs
> seems indicated. It promises both significant compression and CPU
> performance. The intended use case is for Android device read-only
> partitions with both limited storage and CPU/power capacity.

I briefly reviewed the document and found that LZ4 is the only supported algorithm in EROFS, even if EROFS has perfect layout of the filesystem, it's to good to be true it can outperform the XZ in compression ratio tests. The difference for SquashFS LZ4hc 1M vs XZ 1M is >40%.

On Fri, Jan 24, 2020 at 2:17 AM Chris Murphy <lists@colorremedies.com> wrote:

On Mon, Jan 20, 2020 at 1:38 AM Bohdan Khomutskyi <bkhomuts@redhat.com> wrote:
>
> In my previous message, I mentioned that CPU is underutilized during installation. I haven't investigated further why, but I suspect it's due to the inefficiency caused by the usage of the loop device and/or inefficiency in the rsync itself.

Could this be read amplification?

This paper on erofs suggests read amplification can be a significant
side effect with squashfs. It could be exacerbated with random reads,
and I expect it gets worse with larger block size. That's probably
mitigated with unsquashfs.

Specifically page 4, 2nd paragraph.
https://www.usenix.org/system/files/atc19-gao.pdf

This also makes me wonder about the memory consumption effect of a 1M
block size, especially for Fedora ARM where it looks like Raspberry Pi
2B

Most of the ARM images are raw.xz but some are bootable ISOs, dvd and
netinstall. And those contain a squashfs sysroot. Even if there's no
out of memory problem, it could result in paging. All ISOs setup
swap-on-ZRAM these days, lives, DVD, and netinstall. I think the ARM
case needs testing before committing to 1M block size across all ISOs,
or implementing changes in Fedora release engineering.

--
Chris Murphy