2009/1/15 Matt Sealey <matt@genesi-usa.com>:
Okay I grabbed the git repo, there is one line at the bottom that determines which fs it's using;
find . |cpio -H newc -o |gzip -9 > $outfile
Well, I guess then it'd be easy at this stage to let distributions pick which initramfs type they want to load. <snip>
And switching to another FS wouldn't be that difficult. You don't have to touch thousands of lines of code. But I don't see any reason to do that. Just because "Gentoo does that" doesn't convince me.
I am not sure of the design decisions behind some Linux distributions using squashfs vs. traditional cpio archives, but it may be just moving with the times and using what is easiest and best. <snip>
Remember: The initrd is built on customer's (read: users') systems while the installation images are only built at SUSE in a defined environment (rpm build root).
One advantage I can think of immediately is that the squashfs tools are multi-threaded. The same advantage was given out for the move to LZMA for packaging; decompressing them is faster on SMP systems because of the nature of the LZMA decompression process (and making them is faster too).
This stuff gets loaded into RAM on boot, and then the kernel has to decompress it, and mount the initial /, then use pivot root to mount the real root filesystem from disk. The size of that initrd, should generally be small enough eg) 4MiB that decompression time ought not to be very significant. According to http://www.squashfs-lzma.org/, the LZMA is only going to compress much tighter than gzip if you use large block sizes, like 1MiB. For relatively small files like the core kernel and initrd, the gains cannot be as great as for the file system on a Live CD, a 10% benefit would probably be swallowed up by the slower decrompression quoted (10-20MB/s on a 2GHz system).
cpio is just globbing up files from the filesystem, mksquashfs could be tuned to produce an optimal order for files to be compressed, and compress multiple files at once, giving faster initrd creation. It doesn't take too long as it is, but.. any speedup is a speedup.
Compressing a pipeline, leads to tighter compression, than doing it the "zip way" and archiving a collection of compressed small files. The cpio/gzip method, is almost certainly decreasing load times, as it occurs faster than typical disk transfer speeds of about 30MB/s - 50MB/s. LZMA would actually be slower on very many systems according to their own page. I get better than 20MB/s on even very old hardware with slow 450Mhz CPU.
The other advantage is that squashfs is an in-place filesystem (like cramfs for all it's flaws) so there is no "Unpacking initramfs" step, and no ramdisk to be created, and no need to free the initrd memory once it's unpacked, basically saving time and also overall memory consumption for boot.
The purpose is a memory / filesystem, that then allows the loaded kernel to access the hard disk, CD, Flash chip, PROM, battery backed RAM or whatever / is actually stored on. It needs to contain the drivers and minimal code to mount the real /. The kernel requires to decompress itself, and decompress and unpack (or mount) the initrd in RAM. After it's been loaded, so it can then go find the hardware it needs to bring up the system.
One thing I did notice in dracut is /bin/bash is required in the initrd. Why? What does any of the initrd stuff do that requires bash scripting?
That's probably one of the Fedora-ism's that are mentioned in the post about it. Many distro's use a different shell than bash, as a boot optimisation, because well written scripts don't rely on bash specific extensions. -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kernel+help@opensuse.org