[arch-general] Multi-threaded mkinitpcio

[Amin Vakil]

> 
> As it's true for pretty much all update process for pretty much every OS
> in the world, things can break if the update is interrupted.
> 
I meant as other linux distros keep multiple kernel versions, if
something happens during kernel update you can always boot to another
kernel which I've done on CentOS servers before when update has broken
during kernel update.
> 
>   For my particular setup, running `mkinitcpio -P` yields those times:
> ------------------------
> real	1m8.320s
> user	0m24.742s
> sys	0m12.806s
> ------------------------
> Half of the time mkinitcpio was waiting for disk I/O. Most likely
> `find`, but that?s only mu guess.
> 
As my Arch is on SSD I suppose hard drive is not a bottleneck.
> 
> 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.
> 
Good point, I've checked and my SSD is OK.
> 
> change the COMPRESSION variable to lz4 ou lzop in your /etc/mkinitcpio.conf
> : it will considerably reduce the compression time.
> 
Great suggestion, I've compared with gzip and it's really considerably
faster. (Four images are built, linux (default, fallback),
linux-hardened (default, fallback))

gzip:
real	1m42.140s
user	1m22.717s
sys	0m23.493s

lz4:
real	1m1.120s
user	0m44.310s
sys	0m21.785s

cat (without compression):
real	0m59.477s
user	0m43.050s
sys	0m21.946s

To sum it up I will enable lz4 compression to benefit from both reduced
time and saving space. Also I'm planning to read wiki on how to safely
disable fallback. I'm using LVM on LUKS method and I suppose fallback
image cannot boot my Arch, so it doesn't help in case of an accident.

Thank you all

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <https://lists.archlinux.org/pipermail/arch-general/attachments/20200403/63ae6d07/attachment.sig>