2009/1/14 Matt Sealey <matt@genesi-usa.com>:
Greg KH wrote:
On Wed, Jan 14, 2009 at 03:12:32PM -0600, Matt Sealey wrote:
What advantages do you know of?
Appending files is a breeze compared to a cpio archive. Replacing the same file in a cpio usually means dumping and remaking it. mksquashfs can get rid of the original file and relink the new one at the end.. it would mean you can do clever tricks like building half the initrd or filesystem image, doing something else based on that result, and then appending further processed data.
That might help with an issue I've stumbled into. I wanted to change from using, the pata_pdc202xx_old driver, to using ATA/IDE pdc202xx_old, and the new mkinitrd script was relying on udev and what was used in the current system. The expert on the mkinitrd changes, said that there wasn't now a way to make this change. So the workround to avoid a particular driver, became a tortuous fresh install, then remake the initrd and copy over to the original installation. Similarly, I can imagine it being reasonable for a sysadmin to install using plain partitions, then with a burned in machine, want to move / and /boot over to a RAID array, or / in LVM managed partition when the box is live in production. Being able to manipulate the initrd's, with standard tools could help considerably in recovering a system, or where hardware change requires new driver support for /, but you don't yet have a running system to build the new initrd on.
I guess it's just as easy with cpio with clever scripting.
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. Having squashfs inside cpio/gz would just make things more complicated, adding an unecessary extra layer for little benefit on an installed system.
There's also the potential for slightly better compression if there was some known sort order of the files so they could be grouped together.
Perhaps in the future LZO (not as great compression as gz but much faster to decompress and FAR less memory intensive of course) or LZMA (better, but a bit heavier of course. Always a trade-off) sometime, perhaps, maybe. I'm not counting that but it would be a benefit worth risking a little work on.
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.
For no other good reason than it ends up that someone wants to loop mount a root filesystem at some point during the life of the install, be it just during install (as is on the SUSE DVD common/rescue images etc.), or using it to pre-seed the root filesystem and then union mounting a real root on top (I can't remember exactly where I saw this trick now, but I think it was GoboLinux.
All the kernel modules are in the initrd, not on the main filesystem.. it hasn't the finesse of the SUSE "dynamically make an initrd based on your machine", but it's no more clunky than the SUSE "the installer initrd cpio actually contains a big squashfs of all the modules and loop mounts it and sometimes in the betas it's not there (bug 437796)" :)
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.
Granted it's nothing you can't do with cpio, but.. some places people decided, if you're going to make a filesystem archive which gets loaded or mounted, they may as well all be the same type. And SUSE is already using it in the installer.
That initrd is there to be loaded into RAM by the boot loader, to provide the kernel code to mount the real / filesystem. So the cpio gz format was what the kernel supported and needed. 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. 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.
are we going to see a move to it at some point and have the thing built in with more use of the format?
I think the goal with mkinitrd is to work with the community to come up with a common tool that all the distros use. Dave Jones is currently working on a first cut at this, and then we will all get together to go from there. If it happens to use squashfs instead of cpio, well, that will be up to the community, not just us.
I don't think you would get too many objections.. there's also no reason (like mk_image in installation-images) that it can't use a bunch of different image types. Who knows, squashfs could be superceded by something else in the future. You know how usually goes.. it's better to be flexible
Being able to mount the initrd and alter, and add modules, not automatically chosen would solve some issues. Presumbably some FUSE scheme could do the same, with the current format? Better compression, and/or performance considerations of the initrd format would be secondary in my view. Does Dave Jone's consider altering the format? My impression was it was more an attempt to having a sane unification of code with many special cases, to reduce duplication of effort. Dracut - "Unlike existing initramfs's, this is an attempt at having as little as possible hard-coded into the initramfs as possible. The initramfs has (basically) one purpose in life -- getting the rootfs mounted so that we can transition to the real rootfs. This is all driven off of device availability." On a running system that approach would appear compatible with a retro-fit for older kernels, which might be a goal of a cross distro project, though the main 2.4 holdouts I came across last year, seem to have found a way round their permanent objects and now use 2.6. That might be a source of objections. -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kernel+help@opensuse.org