Mailinglist Archive: opensuse-factory (422 mails)

< Previous Next >
[opensuse-factory] Re: [opensuse-kernel] Squashfs
  • From: Rob OpenSuSE <rob.opensuse.linux@xxxxxxxxxxxxxx>
  • Date: Thu, 15 Jan 2009 11:23:12 +0000
  • Message-id: <ce9d8ed60901150323t62341d98p890ed54a98db3cb@xxxxxxxxxxxxxx>
2009/1/14 Matt Sealey <matt@xxxxxxxxxxxxxx>:
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-factory+unsubscribe@xxxxxxxxxxxx
For additional commands, e-mail: opensuse-factory+help@xxxxxxxxxxxx

< Previous Next >
Follow Ups