Bernhard Walle wrote:
Hi,
* Matt Sealey [2009-01-14 16:04]:
Aren't these two codebases doing EXACTLY the same thing but in different ways, here?
Some room for consolidation, I'd think.
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.
Who else? Gentoo, GoboLinux.. umm.. Knoppix et al. :)
Fedora? Debian? Ubuntu?
Isn't this merely because squashfs is an afterthought for all these distributions, which have been using cpio archives since the deep dark days? It's going to be in mainline in 3 months.
Arch Linux also uses cpio.gz. Honestly, I don't care what "GobolLinux" does.
I would say this is a little narrow-minded >.<
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.
One advantage of cpio.gz is that you've the tools always there.
Only because they're installed by some package which is in one of the default patterns :)
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). 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. 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. 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? It's an 800k shell for which 99.999% of what you need to do in an initrd only needs a 100k shell. Debian and Ubuntu already use 'dash' for this to reduce the size of the initrd, memory footprint on boot and of course load/link time for the shell (starting lots of scripts = some overhead) There is a comment about this on the dracut wiki page. I think it's worth looking into. You're not shaving a great deal of time on it but any time saved is time well saved. I really am curious what exactly goes into these initrd's that really really needs bash and if it is that difficult to change it round (Ubuntu certainly managed it, and dash is the default "sh" too). -- Matt Sealey -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kernel+help@opensuse.org