Rob OpenSuSE wrote:
2009/1/14 Matt Sealey <matt@genesi-usa.com>:
Mounting a filesystem and using standard tools is far more sysadmin friendly. The main drawback would seem to be, that the new format would be opaque to older kernels (minor?), but also need kernel support for the purpose.
That's true but that's up to mkinitrd to decide which it makes or not. Since it's generated on the fly, based on the current system..
Having squashfs inside cpio/gz would just make things more complicated
Nobody is suggesting that this be a solution, although it IS the solution used for mkinstallinitrd in installation-images - it makes a cpio.gz initrd and stuffs in squashfs files full of modules and other stuff, and loop mounts them via Linuxrc (after loading the squashfs module and loop module which are the only ones in the cpio.gz). That's already overcomplicated.
It would seem wise to err on side of heavier compression and processing. bzImage has been used for a very long time, to decompress the kernel on older CPUs with less memory than is standard now, so it is likely pointless to go to a looser compression for decompression speed and lower memory consumption.
bzImage etc. only exist for bootloaders which could not load files bigger than a certain size, which was kind of a problem when the kernel and initrds were getting rather large. Sine you have to decompress the kernel to run it, bzImage doesn't save any memory at all (it just takes the bootloader longer to decompress it and bzip requires far more memory to decompress than gzip). Once it's decompressed, the original bzImage data is discarded and only the uncompressed kernel and (and compressed initrd data) are left in RAM when the kernel entry point is called.
Can that support live installion of new modules? Logically the initrd has been a minimal size on typical running systems, and should ideally be the minimal set of modules to get / (and /lib/modules) mounted. Then "all" of the modules are in 1 place, and the initrd only needs changing when a kernel update, or hardware change occurs.
As an example, you could build a standard initrd and then just append the modules to it with mksquashfs, or add config options to append a new module when a new kmp is installed which may be needed earlier in boot (for instance making sure a new raid controller is brought up). This is as easy with mksquashfs as it is with cpio because of the cpio format (iirc just concatenating cpio archives works), but mksquashfs is more flexible about it.
Installers may benefit from the extra layer of mounting a special purpose filesystem type, but if the kernel expects a cpio archive in RAM, and not the SqaushFS format, then you gain nothing.
Squashfs patch makes the kernel expect Squashfs as well as a bunch of other formats (cramfs, ext2 etc.) besides cpio that the kernel already supports. mkinitrd (or dracut) gets run in the kernel-flavor.arch.rpm post.sh script on INSTALLATION, which means basically you can tell when and if the right filesystem is available in the kernel (this decision is left up to the kernel maintainers who know the kernel version and RPM release the support started, and can check for it - hell, there's not even a need for that, CONFIG_SQUASHFS=y in /boot/config-VERSION-FLAVOR is enough notice that you can support that format.
One reason perhaps for use of cpio, was that the format was absolutely stably fixed. If SquashFS got used in the suggested way, then it's format needs to be similarly stable, with a mature tool chain.
Phillip Lougher is doing this right now which is why squashfs is going into mainline in 10.. 9.. 8... The reason I bring it up is because it will be in mainline, it will be available in every kernel-source after that without a patch, the format has to be stable at that point (4.0) and basically it is a better solution in a bunch of ways, some huge, some not so huge, some may even be negative, but it is in common use, it is a flexible format and a real filesystem (I remember when all our initrds were cramfs..) and has many other benefits outside of initrds (Linuxrc already relies on it for the root filesystem, common/rescue/etc. in the installer) and would provide a common filesystem compression format to be used across the whole distribution. If they ever manage to support LZMA in squashfs (which requires support in the kernel first, which people seem to be dilly-dallying about right now), then there is no reason why the DVD images (gnome/kde/x11/base) can't be compressed in it either. -- Matt Sealey -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kernel+help@opensuse.org