On Thu, Jan 15, 2009 at 8:53 AM, Rob OpenSuSE <rob.opensuse.linux@googlemail.com> wrote:
The problem that seems to be overlooked is that, SquashFS is only just making it into the mainline kernel. initrd's are from kernel hacker point of you, non-broken and functioning perfectly satisfactorily using the cpio/gzip format.
Squashfs support has been built in and built from every kernel package I've seen on SUSE since somewhere around version 8. It is not like it is not ready on peoples' systems *right now*. Only vanilla kernels won't see it, which may cause some problem for people who love to use vanilla kernels, but that gets fixed when squashfs is mainlined.
So to utilise a SquashFS format initrd, requires this kernel change.
A tiny one.. Check your /lib/modules directory, check the patches in kernel-source (read series.conf or so). The patch is there. The module is built. The only change is an "m" to a "y"..
A distro version which then uses this format, is not going to be able to support booting with older kernels, hence unsuitable for kernel hackers and support, who may very well need to do such things, unless the support is backported into their "stable" kernels.
mkinitrd is run at kernel install time, so it can pick and choose which filesystem to use dependant on the kernel configuration in use, versioning, and a bunch of other ways.
It seems unlikely to me, that a initrd unification project could make changes that might prove contraversial, more they're going to need to build consensus, minimising changes that ppl may object to.
So perhaps a FUSE based initrd admin tool, or unpack and repack scripts, is a more feasible solution to the difficulties disovered with 11.1 mkinitrd for the sysadmin.
The scripts are already there.. I don't remember any PROBLEMS for the sysadmin with the current system, it just seems opportune to move to consolidate all the root filesystem/installer filesystems and initramfs filesystems to a common format and further consolidate the scripts that build them - after all, they are all just fancy ways of collecting a list of files, stuffing them in a directory and making an archive. At the moment there are several tools and several packages and a lot of weird Perl scripts and shell scripts mixed in to do most of what dracut intends to do, just with a different file list. Another idea in the dracut wiki page is of course, to detect drivers at runtime instead of at buildtime - rather than pick drivers out from the running system, to load all the drivers into an initrd and pick the ones required. This increases the size of the initrd but it means a common initrd works on every system which runs the same kernel. With cpio archives, this is decompressed into ramfs/tmpfs or similar after the main kernel initialization is done, which leaves a copy of every possible kernel module in RAM, potentially 'forever'. Since the cpio is decompressed you basically have this glob of modules living there uncompressed. Loading them basically doubles the footprint of every loaded module. And not to mention, the footprint of every unloaded module stays around. A compressed filesystem such as squashfs basically eliminates some of that effect by not requiring the decompression step.
True, but gzip is the kernel decrompession and uses less memory than LZMA, and CPU
You're not doing anything else at the point that cpio archive is decompressed. CPU usage at that stage is moot. The fact is that LZMA uses less memory and has faster decompression than gzip. This is also moot, though, since lzma compressed cpio is not supported (and won't be until LZMA is in the kernel, which is also stopping squashfs from supporting LZMA)
folk with embedded class low power hardware, whereas LZMA might be a problem on older CPUs.
Not at all. The problem is that LZMA increases memory usage on COMPRESSION (just doing a 40MB tarball now, top is telling me %MEM for lzma is 50.9 (and it's taken out my disk buffers to do it) - for gzip it's 0.9. Decompression is much lighter - it's directly related to the block size used so for a 128KiB block, it's around 128KiB. For compression methods like LZO the decompression memory is 64KiB. Compression is not as good (actually it's very similar to gzip give or take 10-20% depending entirely on the data) but decompression is lighter and faster than gzip.
The current mkinitrd wraps up stuff in a non obvious way. I suspect FUSE, might provide a suitable alternative, to permit changes to the generated initrd, where udev's copying of currently booted system.
I don't think fuse works any better than loop mounting a squashfs here except that squashfs is read only and a fuse filesystem may be writable.. but this means the kernel needs to read this fuse-based filesystem... not a good plan.
But I much prefer the idea of being able to mount the initrd, like an iso file and make changes, to current unpack, and repack scheme.
mksquashfs, unsquashfs.
The real point is, the current mkinitrd in 11.1, has a flaw through using udev, which fixed other issues (not ones that are clear to me) that moving to a mountable format might ameliorate.
It's a Pro reason for Novell/SuSE to support the SquashFS initrd idea, when Dave Jones is seeking input. Though I guess I could email him, pointing out the bug report involved, I am sure there are other Pro/Con that I am not fully party to.
Bug report?
Great to make that point clear. But it means SqaushFS must be compiled in, and not a loadable module, like most filesystems.
You change one byte in config/arch/* config files in kernel-source and suddenly everyone has support. The patch is already there.
Now that the SquashFS has been accepted, it'll be easier to add kernel support for LZMA
Squashfs has no impact on the acceptance of LZMA in the kernel.
and then LZMA patches to SquashFS, if the change has technical merit and meets user requirements.
Modern systems would likely benefit, without seeing the downsides, that low powered hardware might experience.
I don't think there would be any downsides but let's stop talking about LZMA now. If the kernel supports LZMA it will also support cpio-compressed LZMA archives (and lzImage boot images :) so the advantages are basically only really the extra flexibility of squashfs being a real compressed filesystem. -- Matt Sealey <matt@genesi-usa.com> Genesi, Manager, Developer Relations -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kernel+help@opensuse.org