[opensuse-kernel] Squashfs
I just noticed that while squashfs 3.4 kernel module is used on the -default kernel, the squashfs tools on both PowerPC and x86 repos are stuck at 3.2 neko@frodo:~> mksquashfs -version mksquashfs version 3.2-r2 (2007/01/15) Is there any particular reason for this? Is there an update planned? Also, more for the kernel guys.. is there any reason why the mkinitrd etc. stuff relies on cpio archives when the SUSE kernel is built with squashfs (granted as a module), all the rescue/install images are squashfs? It does not provide any remarkably better compression - in fact I tested 100k larger filesystem with mksquashfs 3.2 but then mksquashfs 3.2 refuses to use large block sizes so the compression is lower than it could be, also mksquashfs 3.4 supposes a 10% improvement and unsquashfs supposes a 40% improvement in speed in creation and extraction (we will ignore the kernel improvements as, they are in the kernel already).. .. But a few tests in performance usually always show that accessing a squashfs initrd mounted to RAM is faster than a cpio initrd in RAM. It also has a few extra little advantages here and there but I do not know if they are worth it, but I do know that managing squashfs filesystems is a billion times easier than pushing cpio archives around. Since squashfs is going to be in the kernel mainline at some point (it's in Linus' tree) and everyone and his dog makes squashfs initrds, are we going to see a move to it at some point and have the thing built in with more use of the format? -- Matt -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kernel+help@opensuse.org
On Wed, Jan 14, 2009 at 03:12:32PM -0600, Matt Sealey wrote:
I just noticed that while squashfs 3.4 kernel module is used on the -default kernel, the squashfs tools on both PowerPC and x86 repos are stuck at 3.2
neko@frodo:~> mksquashfs -version mksquashfs version 3.2-r2 (2007/01/15)
Is there any particular reason for this? Is there an update planned?
Someone needs to kick the owner of the userspace squashfs tools to get them to update them. If you could be so kind as to file a bug against the package, that would help.
Also, more for the kernel guys.. is there any reason why the mkinitrd etc. stuff relies on cpio archives when the SUSE kernel is built with squashfs (granted as a module), all the rescue/install images are squashfs?
No specific reason, other than "that's just the way we've always done it." Do you really want to touch that mkinitrd code to change this? :)
It does not provide any remarkably better compression - in fact I tested 100k larger filesystem with mksquashfs 3.2 but then mksquashfs 3.2 refuses to use large block sizes so the compression is lower than it could be, also mksquashfs 3.4 supposes a 10% improvement and unsquashfs supposes a 40% improvement in speed in creation and extraction (we will ignore the kernel improvements as, they are in the kernel already)..
.. But a few tests in performance usually always show that accessing a squashfs initrd mounted to RAM is faster than a cpio initrd in RAM.
Are you sure? What kind of performance difference is there?
It also has a few extra little advantages here and there but I do not know if they are worth it, but I do know that managing squashfs filesystems is a billion times easier than pushing cpio archives around.
But these are generated "on-the-fly" and don't need to be managed by anything, right? What advantages do you know of?
Since squashfs is going to be in the kernel mainline at some point (it's in Linus' tree)
Yes, it will be in 2.6.29, and is already there in 2.6.29-rc1.
and everyone and his dog makes squashfs initrds,
Who else?
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. thanks, greg k-h -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kernel+help@opensuse.org
Greg KH wrote:
On Wed, Jan 14, 2009 at 03:12:32PM -0600, Matt Sealey wrote:
I just noticed that while squashfs 3.4 kernel module is used on the -default kernel, the squashfs tools on both PowerPC and x86 repos are stuck
Someone needs to kick the owner of the userspace squashfs tools to get them to update them. If you could be so kind as to file a bug against the package, that would help.
I am doing it now, but also going through another bunch of bugs.. also I'm a little wary of the actual category to put it in but, oh well.. Other can do for now.
Also, more for the kernel guys.. is there any reason why the mkinitrd etc. stuff relies on cpio archives when the SUSE kernel is built with squashfs (granted as a module), all the rescue/install images are squashfs?
No specific reason, other than "that's just the way we've always done it."
Do you really want to touch that mkinitrd code to change this? :)
I was sure at some point I was reading mkinitrd code and saw some option for initrd_fs which specified a type, which said "ext2" was the default. This is obviously dead wrong (since it's always a cpio). Looking at it again, it turns out mk_image (argh what's with these names, I just had a fight with mkimage from U-Boot and jigdo) supports squashfs through the Conv2Image perl module. Aren't these two codebases doing EXACTLY the same thing but in different ways, here? Some room for consolidation, I'd think.
It does not provide any remarkably better compression - in fact I tested 100k larger filesystem with mksquashfs 3.2 but then mksquashfs 3.2 refuses to use large block sizes so the compression is lower than it could be, also mksquashfs 3.4 supposes a 10% improvement and unsquashfs supposes a 40% improvement in speed in creation and extraction (we will ignore the kernel improvements as, they are in the kernel already)..
.. But a few tests in performance usually always show that accessing a squashfs initrd mounted to RAM is faster than a cpio initrd in RAM.
Are you sure? What kind of performance difference is there?
I'm trying to benchmark that now, I'm wondering what I can actually do.. maybe I will grab the 11.1 common and make a cpio out of it and loop mount them both and do something with it, but it is sort of beyond my means at the moment. I've run out of hardware that's not in permanent use.. benchmarking on a system running an rpm build is not fair :) I will endeavour to poke at it though. In the meantime I bugged the author, since he would know :D
It also has a few extra little advantages here and there but I do not know if they are worth it, but I do know that managing squashfs filesystems is a billion times easier than pushing cpio archives around.
But these are generated "on-the-fly" and don't need to be managed by anything, right?
Indeed..
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. I guess it's just as easy with cpio with clever scripting. 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.
Since squashfs is going to be in the kernel mainline at some point (it's in Linus' tree)
Yes, it will be in 2.6.29, and is already there in 2.6.29-rc1.
and everyone and his dog makes squashfs initrds,
Who else?
Gentoo, GoboLinux.. umm.. Knoppix et al. :) 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)" :) 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.
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 :) -- Matt Sealey Genesi, Manager, Developer Relations -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kernel+help@opensuse.org
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.
http://lwn.net/Articles/311890/
Who else?
Gentoo, GoboLinux.. umm.. Knoppix et al. :)
Fedora? Debian? Ubuntu? Arch Linux also uses cpio.gz. Honestly, I don't care what "GobolLinux" does. I think your fs parameter whose default is ext2 is the fs type of the root file system and is automatically detected nowadays. 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. One advantage of cpio.gz is that you've the tools always there. 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). Bernhard (current maintainer of 'mkinitrd') -- Bernhard Walle, SUSE LINUX Products GmbH, Architecture Development "I have always wished that my computer would be as easy to use as my telephone. My wish has come true. I no longer know how to use my telephone." -- Bjarne Stroustrup -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kernel+help@opensuse.org
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
2009/1/15 Matt Sealey <matt@genesi-usa.com>:
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. <snip>
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. <snip>
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).
This stuff gets loaded into RAM on boot, and then the kernel has to decompress it, and mount the initial /, then use pivot root to mount the real root filesystem from disk. The size of that initrd, should generally be small enough eg) 4MiB that decompression time ought not to be very significant. According to http://www.squashfs-lzma.org/, the LZMA is only going to compress much tighter than gzip if you use large block sizes, like 1MiB. For relatively small files like the core kernel and initrd, the gains cannot be as great as for the file system on a Live CD, a 10% benefit would probably be swallowed up by the slower decrompression quoted (10-20MB/s on a 2GHz system).
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.
Compressing a pipeline, leads to tighter compression, than doing it the "zip way" and archiving a collection of compressed small files. The cpio/gzip method, is almost certainly decreasing load times, as it occurs faster than typical disk transfer speeds of about 30MB/s - 50MB/s. LZMA would actually be slower on very many systems according to their own page. I get better than 20MB/s on even very old hardware with slow 450Mhz CPU.
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.
The purpose is a memory / filesystem, that then allows the loaded kernel to access the hard disk, CD, Flash chip, PROM, battery backed RAM or whatever / is actually stored on. It needs to contain the drivers and minimal code to mount the real /. The kernel requires to decompress itself, and decompress and unpack (or mount) the initrd in RAM. After it's been loaded, so it can then go find the hardware it needs to bring up the system.
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?
That's probably one of the Fedora-ism's that are mentioned in the post about it. Many distro's use a different shell than bash, as a boot optimisation, because well written scripts don't rely on bash specific extensions. -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kernel+help@opensuse.org
* Rob OpenSuSE [2009-01-15 14:18]:
That's probably one of the Fedora-ism's that are mentioned in the post about it. Many distro's use a different shell than bash, as a boot optimisation, because well written scripts don't rely on bash specific extensions.
Define well-written. If you rely only on POSIX, you have two problems: - there is no real test shell available that implements POSIX and only POSIX, - you need lots of external tools for everything, which is slow, - sometimes bash-specific syntax is more readable than POSIX syntax. I think dash implements bash-specific syntax and not only POSIX. Not as much as Bash itself, but much more than POSIX. Bernhard -- Bernhard Walle, SUSE Linux Products GmbH, Architecture Development -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kernel+help@opensuse.org
2009/1/15 Bernhard Walle <bwalle@suse.de>:
* Rob OpenSuSE [2009-01-15 14:18]:
That's probably one of the Fedora-ism's that are mentioned in the post about it. Many distro's use a different shell than bash, as a boot optimisation, because well written scripts don't rely on bash specific extensions.
Define well-written. If you rely only on POSIX, you have two problems:
- there is no real test shell available that implements POSIX and only POSIX, - you need lots of external tools for everything, which is slow, - sometimes bash-specific syntax is more readable than POSIX syntax.
I think dash implements bash-specific syntax and not only POSIX. Not as much as Bash itself, but much more than POSIX.
No need, you make the point for me. Other shells implement the features that are going to make sense for such scripts. I'm quite happy for "well written" to be works, on shells used to bring up a system. I'd be very suprised if mounting a root file system, has to rely on obscure bash specific features. Remembering more, actually Fedora uses "nash" according to discussion at LWN of Dave Jone's suggestion. So that suggestion for "/bin/bash" being the path used is incorrect. So I have no idea why that path would be bash, and also evidence to suggest that it's proven to be a poor choice in practice (Fedora nash, Ubuntu dash). Choosing POSIX as a baseline would preclude a benefit of accessible source, where a shell builtin might be a much more elegant solution. -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kernel+help@opensuse.org
On Thu, Jan 15, 2009 at 9:06 AM, Rob OpenSuSE <rob.opensuse.linux@googlemail.com> wrote:
So I have no idea why that path would be bash, and also evidence to suggest that it's proven to be a poor choice in practice (Fedora nash, Ubuntu dash).
To be fair, nash has also been proven to be a poor choice in practice. I don't know if dash is better, it's just SMALLER than bash, and has a much lower impact on the system regarding a) loading the binary (although from ram I doubt you could really say it takes a long time) b) dependencies on other libraries (linker time, which is the real problem) c) size of the initrd (even static dash is smaller than the dynamically linked bash) -- 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
2009/1/15 Matt Sealey <matt@genesi-usa.com>:
On Thu, Jan 15, 2009 at 9:06 AM, Rob OpenSuSE <rob.opensuse.linux@googlemail.com> wrote:
To be fair, nash has also been proven to be a poor choice in practice. I don't know if dash is better, it's just SMALLER than bash, and has a much lower impact on the system regarding
Ubuntu introduced it with 7.10 IIRC and it is used for all their start up scripts, not just early stage booting, and a large speed up was claimed due to it's greater efficiency with only a small number of alterations to scripts. /bin/bash may be the path, but actually something else in practice. I doubt that GNU bash would become the shell of choice for this task, though perhaps it has attractions by avoiding maintenance issues. Folk like booting systems and using Busy Box tools, so presumbably something lightweight would actually be the final choice. People do care about boot speed. -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kernel+help@opensuse.org
On Thu, Jan 15, 2009 at 10:35 AM, Rob OpenSuSE <rob.opensuse.linux@googlemail.com> wrote:
2009/1/15 Matt Sealey <matt@genesi-usa.com>:
On Thu, Jan 15, 2009 at 9:06 AM, Rob OpenSuSE <rob.opensuse.linux@googlemail.com> wrote:
To be fair, nash has also been proven to be a poor choice in practice. I don't know if dash is better, it's just SMALLER than bash, and has a much lower impact on the system regarding
Ubuntu introduced it with 7.10 IIRC and it is used for all their start up scripts, not just early stage booting, and a large speed up was claimed due to it's greater efficiency with only a small number of alterations to scripts.
Ubuntu also have the simple policy inherited from Debian that ALL init scripts MUST be posix compliant and be able to be run through the standard GNU sh. It turns out that ash/dash/nash are smaller than GNU sh and just as compatible. I don't think SUSE has that policy.
/bin/bash may be the path, but actually something else in practice.
No, usually /bin/bash is always /bin/bash - and /bin/sh is redirected. On SUSE it's to /bin/bash. On Debian/Ubuntu it's to /bin/dash. On other systems sh isn't redirected at all and some it's csh or ash.. :) What's clear is that whichever shell is picked for the initrd it needs to work, and if dash won't work it needs to be bash, explicitly (and /bin/sh needs to be aliased to it as it already is).
doubt that GNU bash would become the shell of choice for this task, though perhaps it has attractions by avoiding maintenance issues.
This is exactly the explanation I got from the powers that be.
Folk like booting systems and using Busy Box tools, so presumbably something lightweight would actually be the final choice. People do care about boot speed.
But not enough that they want to break it. I am dropping the bash/dash thing because there is no will to upset the boat here just to speed up boot by a few seconds needs significant reworks of init scripts and significant work by maintainers on a new shell. Squashfs is already maintained by the installer team though :D -- 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
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
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
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. So to utilise a SquashFS format initrd, requires this kernel change. 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. 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. 2009/1/15 Matt Sealey <matt@genesi-usa.com>:
Rob OpenSuSE wrote:
2009/1/14 Matt Sealey <matt@genesi-usa.com>:
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.
Agreed.
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.
It was also nice, because you could boot a kernel off a floppy disk :)
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.
True, but gzip is the kernel decrompession and uses less memory than LZMA, and CPU. It's been used for a long time, so should not upset folk with embedded class low power hardware, whereas LZMA might be a problem on older CPUs. The "less memory" referred to systems where gzip method was successfully used, not the effect of using bzImage or gzip for initrd. We agree again there. The boot loader doesn't decompress the kernel, as far as I understand, it's the kernel that does that, effectively unpacking itself into it's final position in memory. That feature allowed the kernel to work with very simple minimal boot loaders on things like floppies.
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
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. 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. 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.
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.
Great to make that point clear. But it means SqaushFS must be compiled in, and not a loadable module, like most filesystems.
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.
Now that the SquashFS has been accepted, it'll be easier to add kernel support for LZMA, 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. -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kernel+help@opensuse.org
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
2009/1/15 Matt Sealey <matt@genesi-usa.com>:
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.
The linux kernel team "kernel hacker" use all kinds of distro's not just SuSE, and as Greg KH said "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." So the questions he asked, wanting numbers matter, as does that objection, the advocates of change need to be provide evidence. There are end user benefits to mountable initrd's, and would have been a much better workround for one bug, than what I actually had to do. -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kernel+help@opensuse.org
On Thu, Jan 15, 2009 at 10:29 AM, Rob OpenSuSE <rob.opensuse.linux@googlemail.com> wrote:
2009/1/15 Matt Sealey <matt@genesi-usa.com>:
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.
The linux kernel team "kernel hacker" use all kinds of distro's not just SuSE, and as Greg KH said
This is an openSUSE mailing list. I'm not talking about all kinds of other distros. Although if I was I'd note that a bunch of them do use squashfs for initrd (and root filesystems unioned under hard disks) It's only Fedora and Debian which don't but this is most of a factor of "we've been using mkinitramfs since 1997 anyway, and didn't want to change it to a system which needed a kernel patch". Time has changed! No patch required for modern kernels. And the current kernels are already patched anyway. If you loop mount a squashfs kernel, too, you don't need any special tools to extract files from it - this is how the LiveCD installers work. You just copy the files to the target.
So the questions he asked, wanting numbers matter, as does that objection, the advocates of change need to be provide evidence.
There are end user benefits to mountable initrd's, and would have been a much better workround for one bug, than what I actually had to do.
I don't think mountable initrds is the point (there are very few situations where you need to mount it), it's the CONSOLIDATION of cpio/squashfs as currently used in initrd/roots on the LiveCDs and potentially the DVD images for the standard installation, to use a single build system and a single (loop mountable) filesystem which offers several benefits. You're simply not paying attention to what is going on in the discussion. I don't know why you are talking about "sysadmin problems", because you never qualified it. Or mountable initrds (I was talking about the fact that the installer ALREADY uses squashfs files INSIDE cpio initrds). They aren't the plus points I'm trying to push here. -- 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
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Matt Sealey wrote:
On Thu, Jan 15, 2009 at 10:29 AM, Rob OpenSuSE <rob.opensuse.linux@googlemail.com> wrote:
2009/1/15 Matt Sealey <matt@genesi-usa.com>:
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. The linux kernel team "kernel hacker" use all kinds of distro's not just SuSE, and as Greg KH said
This is an openSUSE mailing list. I'm not talking about all kinds of other distros. Although if I was I'd note that a bunch of them do use squashfs for initrd (and root filesystems unioned under hard disks)
It's only Fedora and Debian which don't but this is most of a factor of "we've been using mkinitramfs since 1997 anyway, and didn't want to change it to a system which needed a kernel patch". Time has changed! No patch required for modern kernels. And the current kernels are already patched anyway.
Except that up until 2.6.29, this would fail on vanilla kernels. It's easy to hand wave away that requirement when you're not using them - but we use them as a debugging tool with users in Bugzilla all the time.
If you loop mount a squashfs kernel, too, you don't need any special tools to extract files from it - this is how the LiveCD installers work. You just copy the files to the target.
I'd hardly call gzip and cpio "special" tools, but I'm listening. I don't really buy your arguments about consolidation by using squashfs everywhere. mkinitrd and mkinstallimage (or whatever it's called) are different tools. The latter is just totally overkill for what most users need, and it's not as if the cpio code is untested or a maintenance burden. What I am interested in are performance numbers. Can you show me how much memory a system booted into the initrd uses? Can you show me how fast it got there? I'd like numbers for both cpio.gz and squashfs. Using the same data set. - -Jeff - -- Jeff Mahoney SUSE Labs -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org iEYEARECAAYFAklvaVcACgkQLPWxlyuTD7KsdQCcCs+IFlwYZXcHlCGC57GB7WzZ wXkAn2PvcxZYb5DspNknEzNddzS1YJMx =P7MD -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kernel+help@opensuse.org
On Thu, Jan 15, 2009 at 10:50 AM, Jeff Mahoney <jeffm@suse.com> wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Matt Sealey wrote: What I am interested in are performance numbers. Can you show me how much memory a system booted into the initrd uses? Can you show me how fast it got there? I'd like numbers for both cpio.gz and squashfs. Using the same data set.
I'm working on running this experiment now and doing benchmarking of the two methods. I need to build a kernel with the timing enabled, rebuild my initrd as squashfs, recompress it (had to install the 3.4 tools first! :) and then find a way to do something other than watch it boot. I'm fairly confident it is better, but we will see. Unfortunately due to a hickup (using rpmbuild instead of build) and an errant typo in an RPM spec I deleted some portions of my /usr/lib directory last night, so the next step before actually doing the test, is to get a working system installed that actually compiles again and/or can get into a desktop :D BTW your new kernel-source and kernel-default.spec seems to work okay to a degree.. I'll be using these, would that be an unfair test or do you want me to use the original? :) -- 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
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Matt Sealey wrote:
On Thu, Jan 15, 2009 at 10:50 AM, Jeff Mahoney <jeffm@suse.com> wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Matt Sealey wrote: What I am interested in are performance numbers. Can you show me how much memory a system booted into the initrd uses? Can you show me how fast it got there? I'd like numbers for both cpio.gz and squashfs. Using the same data set.
I'm working on running this experiment now and doing benchmarking of the two methods. I need to build a kernel with the timing enabled, rebuild my initrd as squashfs, recompress it (had to install the 3.4 tools first! :) and then find a way to do something other than watch it boot.
I'm fairly confident it is better, but we will see.
Unfortunately due to a hickup (using rpmbuild instead of build) and an errant typo in an RPM spec I deleted some portions of my /usr/lib directory last night, so the next step before actually doing the test, is to get a working system installed that actually compiles again and/or can get into a desktop :D
BTW your new kernel-source and kernel-default.spec seems to work okay to a degree.. I'll be using these, would that be an unfair test or do you want me to use the original? :)
No, that would be fine. My main interest is that the data set is the same, regardless of what the contents actually are. I'm not sure how to best measure the time part of it - since the initial load from disk is definitely an important part of it. Booting quickly is one of the things we do want to better. - -Jeff - -- Jeff Mahoney SUSE Labs -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org iEYEARECAAYFAklvb60ACgkQLPWxlyuTD7I3sgCfU0L1Q2W23oK1Sm5r6B5tNCwY gfoAn3Nm5kVysoNzDFw5LO05qRVUqA8F =rUAN -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kernel+help@opensuse.org
2009/1/15 Matt Sealey <matt@genesi-usa.com>:
On Thu, Jan 15, 2009 at 10:29 AM, Rob OpenSuSE
The linux kernel team "kernel hacker" use all kinds of distro's not just SuSE, and as Greg KH said
This is an openSUSE mailing list. I'm not talking about all kinds of other distros. Although if I was I'd note that a bunch of them do use squashfs for initrd (and root filesystems unioned under hard disks)
Ignoring other distributions, and current work in progress is not going to benefit the discussion.
It's only Fedora and Debian which don't but this is most of a factor
Their needs are going to be a consideration in a joint project.
If you loop mount a squashfs kernel, too, you don't need any special tools to extract files from it - this is how the LiveCD installers work. You just copy the files to the target.
That feature is a user benefit, that will IMO ease support in cases similar to problem I found.
So the questions he asked, wanting numbers matter, as does that objection, the advocates of change need to be provide evidence.
There are end user benefits to mountable initrd's, and would have been a much better workround for one bug, than what I actually had to do.
I don't think mountable initrds is the point (there are very few situations where you need to mount it), it's the CONSOLIDATION of cpio/squashfs as currently used in initrd/roots on the LiveCDs and potentially the DVD images for the standard installation, to use a single build system and a single (loop mountable) filesystem which offers several benefits.
You're simply not paying attention to what is going on in the discussion. I don't know why you are talking about "sysadmin problems", because you never qualified it. Or mountable initrds (I was talking about the fact that the installer ALREADY uses squashfs files INSIDE cpio initrds). They aren't the plus points I'm trying to push here
That's rich. I actually emailed in a request relating out of a specific bug report. The exact details are not particularly relevant to the discussion, just supporting the support benefits of being able to fix up, initrd's conveniently rather than suffer the consequences, of mkinitrd utilising the currently booted system. -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kernel+help@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Grumble. Changing the From address so it goes to the kernel list. Matt Sealey wrote:
Greg KH wrote:
On Wed, Jan 14, 2009 at 03:12:32PM -0600, Matt Sealey wrote:
I just noticed that while squashfs 3.4 kernel module is used on the -default kernel, the squashfs tools on both PowerPC and x86 repos are stuck
Someone needs to kick the owner of the userspace squashfs tools to get them to update them. If you could be so kind as to file a bug against the package, that would help.
I am doing it now, but also going through another bunch of bugs.. also I'm a little wary of the actual category to put it in but, oh well.. Other can do for now.
Also, more for the kernel guys.. is there any reason why the mkinitrd etc. stuff relies on cpio archives when the SUSE kernel is built with squashfs (granted as a module), all the rescue/install images are squashfs?
No specific reason, other than "that's just the way we've always done it."
Do you really want to touch that mkinitrd code to change this? :)
I was sure at some point I was reading mkinitrd code and saw some option for initrd_fs which specified a type, which said "ext2" was the default. This is obviously dead wrong (since it's always a cpio).
Looking at it again, it turns out mk_image (argh what's with these names, I just had a fight with mkimage from U-Boot and jigdo) supports squashfs through the Conv2Image perl module.
Aren't these two codebases doing EXACTLY the same thing but in different ways, here?
Some room for consolidation, I'd think.
Sure, but given limited resources we tend to pick things that are broken to work on. This falls squarely under "if it's not broken, don't fix it." It's not as if the cpio initrds are set in stone once mkinitrd has created them. In the end, adjusting them is as simple as creating a new archive once you've expanded and changed it. - -Jeff - -- Jeff Mahoney SUSE Labs -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org iEYEARECAAYFAklvZrUACgkQLPWxlyuTD7LwyQCdE+St873Gl8Jlr3mrVMlOkjOM 17AAoJkHDR0MgxWHjBVOmjtoKGZQEwXu =xMbB -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kernel+help@opensuse.org
Greg KH wrote:
On Wed, Jan 14, 2009 at 03:12:32PM -0600, Matt Sealey wrote:
I just noticed that while squashfs 3.4 kernel module is used on the -default kernel, the squashfs tools on both PowerPC and x86 repos are stuck at 3.2
neko@frodo:~> mksquashfs -version mksquashfs version 3.2-r2 (2007/01/15)
Is there any particular reason for this? Is there an update planned?
Someone needs to kick the owner of the userspace squashfs tools to get them to update them. If you could be so kind as to file a bug against the package, that would help.
https://bugzilla.novell.com/show_bug.cgi?id=466228 Done :D -- Matt -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kernel+help@opensuse.org
participants (5)
-
Bernhard Walle -
Greg KH -
Jeff Mahoney -
Matt Sealey -
Rob OpenSuSE