>
> 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