On Fri, 3 Apr 2020 04:36:37 +0200, mpan wrote:

Half of the time mkinitcpio was waiting for disk I/O.

Even while it's unlikely that only mkinitcpio suffers from a damaged HDD and even while smartctl not necessarily does show issues of a already damaged aged HDD, I would run smartctl and take a look, if it shows something fishy.

Em abril 3, 2020 3:17 Pascal via arch-general escreveu:

hi,

change the COMPRESSION variable to lz4 ou lzop in your /etc/mkinitcpio.conf : it will considerably reduce the compression time.

And break reproducibility. Also, I wouldn't say considerably. Might be faster, but not leaps and bounds faster. Regards, Giancarlo Razzolini

On 04/04/2020 12:11, Pascal via arch-general wrote:

I don't quite understand where the reproducibility is broken ?

multi-threaded compression does not create a predictable reproducible archive (for xz/zstd).

Amin Vakil says that rebuilding his initrd (when updating kernel and/or modules) takes a lot of time and the final compression phase can be reduced by switching to lz4 or lzop. when you go from xz (which may be his case) to lzop, the difference is remarkable.

Sure, has nothing to do with reproducibility however.

Le ven. 3 avr. 2020 à 14:47, Giancarlo Razzolini a écrit :

...

Em abril 3, 2020 3:17 Pascal via arch-general escreveu:

...

hi,

change the COMPRESSION variable to lz4 ou lzop in your /etc/mkinitcpio.conf : it will considerably reduce the compression time.

And break reproducibility. Also, I wouldn't say considerably. Might be faster, but not leaps and bounds faster.

Regards, Giancarlo Razzolini

thank you for these details. regard, lacsaP. Le lun. 6 avr. 2020 à 05:39, Giancarlo Razzolini via arch-general < arch-general@archlinux.org> a écrit :

Em abril 4, 2020 12:13 Jelle van der Waa escreveu:

...

multi-threaded compression does not create a predictable reproducible archive (for xz/zstd).

Zstd is multi-thread safe, as far as I know, xz is not. But the kernel does not support zstd.

...

Sure, has nothing to do with reproducibility however.

It has, because lzop is the only algorithm that produces unreproducible builds due to them adding their own timestamp, which there's no flag to remove. Of course lzop will be faster than xz, but mkinitcpio's default is gz, which should be comparable, at least in speed, with lzop.

Regards, Giancarlo Razzolini

On 06-04-2020 11:47, Ralph Corderoy wrote:

Hi Giancarlo,

...

Of course lzop will be faster than xz, but mkinitcpio's default is gz, which should be comparable, at least in speed, with lzop. A slap-dash test.

$ perf stat -e instructions gzip <initramfs-linux-lts-fallback >/dev/null Performance counter stats for 'gzip': 19,533,249,541 instructions:u 19.642066695 seconds time elapsed 19.540737000 seconds user 0.100003000 seconds sys $ perf stat -e instructions lzop <initramfs-linux-lts-fallback >/dev/null Performance counter stats for 'lzop': 1,233,520,108 instructions:u 1.129177816 seconds time elapsed 1.092271000 seconds user 0.036743000 seconds sys $

gzip is about twenty times slower.

1,233,520,108 / 19,533,249,541 = 0.0631497644777874596 1.129177816 / 19.642066695 = 0.05748772944994829119

Yes, my computer is probably slower than most, but then perhaps so is the OP's.

Those outputs appear to be from unpacking initramfs. I do think OP and Giancarlo were talking about creating an initramfs . LW

On 06-04-2020 12:43, Ralph Corderoy wrote:

Hi Lone Wolf,

...

...

$ perf stat -e instructions gzip <initramfs-linux-lts-fallback >/dev/null $ perf stat -e instructions lzop <initramfs-linux-lts-fallback >/dev/null

Those outputs appear to be from unpacking initramfs. I do think OP and Giancarlo were talking about creating an initramfs . Oh, sorry for the noise if I'm wrong, but /boot/initramfs-linux-lts-fallback.img is gzip-compressed here. I uncompressed it to give the initramfs-linux-lts-fallback used above. I thought the compression of it was the step OP and Giancarlo were discussing, as you say.

Guess I misinterpretated the command, ralph . Below are some data from my own system (threadripper 1920x , NvME2 ssd) . lzop is about twice as fast as gzip , while xz is very slow. Lone_Wolf $ perf stat -e instructions mkinitcpio --generate testing --compress gzip > /dev/null  Performance counter stats for 'mkinitcpio --generate testing --compress gzip':     16,585,047,999 instructions:u        4.706074377 seconds time elapsed        4.000137000 seconds user        1.187220000 seconds sys $ perf stat -e instructions mkinitcpio --generate testing --compress xz

/dev/null

 Performance counter stats for 'mkinitcpio --generate testing --compress xz':     84,360,010,752 instructions:u       17.415348248 seconds time elapsed       16.756740000 seconds user        1.500338000 seconds sys $ perf stat -e instructions mkinitcpio --generate testing --compress lzop > /dev/null  Performance counter stats for 'mkinitcpio --generate testing --compress lzop':      5,316,618,410 instructions:u        2.426944720 seconds time elapsed        1.695263000 seconds user        1.027651000 seconds sys $