Linux mdadm superblock question.
in [Kernel]
|
Prev: [patch v3 0/2] updated ptrace/core-dump patches for supporting xstate - v3
Next: [PATCH 3/3] mm: Debugging of new livelock avoidance
From: Gabor Gombas on 17 Feb 2010 16:00 On Wed, Feb 17, 2010 at 02:26:46PM +0100, Frans Pop wrote: > That's simply not true, at least not for Debian. If you actually use the > distro tools [1] the only assumptions are made at kernel *installation* > time, not at kernel build time. And that's why network-booted diskless clients and virtual guests have all sort of useless modules loaded; the HW where the kernel package was installed in this case is very different from the HW where the kernel will run. If only there were a switch to prohibit ever looking at the current machine's configuration when generating the initramfs... > I've been using initramfs-tools generated initrds for years without > problems, and that includes "root on LVM on LUKS encrypted partition" > and "root on LVM on RAID" setups. I've tried a couple of times to use a Debian-built initramfs with a custom built kernel. The kernel worked fine without an initramfs (it had everything built in), but it did not boot with the initramfs. Gabor -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: david on 17 Feb 2010 16:20 On Wed, 17 Feb 2010, Nick Bowler wrote: > On 10:41 Wed 17 Feb , david(a)lang.hm wrote: >> On Wed, 17 Feb 2010, Nick Bowler wrote: >>> It takes about half a second for mdadm to assemble my root array, is >>> that what you're referring to? >>> >>> I assume that kernel auto-assembly is no faster, although I've never >>> used it. Regardless, half a second isn't very long to wait. >> >> If you are aiming for a 5-second boot time it's 10% of your total boot >> time. That's a lot for a feature that's not needed. > > Only if the kernel auto-assembly takes zero time, which it obviously > does not. the assembly time would probably be the same, but the initramfs being proposed did not include that time either. David Lang -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Frans Pop on 17 Feb 2010 16:30 On Wednesday 17 February 2010, Gabor Gombas wrote: > On Wed, Feb 17, 2010 at 02:26:46PM +0100, Frans Pop wrote: > > That's simply not true, at least not for Debian. If you actually use > > the distro tools [1] the only assumptions are made at kernel > > *installation* time, not at kernel build time. > > And that's why network-booted diskless clients and virtual guests have > all sort of useless modules loaded; the HW where the kernel package was > installed in this case is very different from the HW where the kernel > will run. Interesting use case. But also a use case for which initramfs-tools probably very simply was never intended. I agree that in this case you probably want to either - have a very generic initrd that supports anything (Debian default) [1] or - provide a list of modules to include in the initrd based on knowing the hardware you want to support (e.g. using /etc/initramfs-tools/modules) and prevent including anything based on the host system. I've never really done that so I don't know if initramfs-tools has any features to support that. > If only there were a switch to prohibit ever looking at the > current machine's configuration when generating the initramfs... Did you ever file a wishlist bug report for that? > > I've been using initramfs-tools generated initrds for years without > > problems, and that includes "root on LVM on LUKS encrypted partition" > > and "root on LVM on RAID" setups. > > I've tried a couple of times to use a Debian-built initramfs with a > custom built kernel. The kernel worked fine without an initramfs (it had > everything built in), but it did not boot with the initramfs. It's obviously hard to comment on something like this without more details (which would be off-topic for this list). [1] Could still leave you with problems if the clients use something fancy for the root fs that uses info copied from /etc. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Nick Bowler on 17 Feb 2010 17:10 On 13:17 Wed 17 Feb , david(a)lang.hm wrote: > On Wed, 17 Feb 2010, Nick Bowler wrote: > > > On 10:41 Wed 17 Feb , david(a)lang.hm wrote: > >> On Wed, 17 Feb 2010, Nick Bowler wrote: > >>> It takes about half a second for mdadm to assemble my root array, is > >>> that what you're referring to? > >>> > >>> I assume that kernel auto-assembly is no faster, although I've never > >>> used it. Regardless, half a second isn't very long to wait. > >> > >> If you are aiming for a 5-second boot time it's 10% of your total boot > >> time. That's a lot for a feature that's not needed. > > > > Only if the kernel auto-assembly takes zero time, which it obviously > > does not. > > the assembly time would probably be the same, but the initramfs being > proposed did not include that time either. This was the *only* time that was included. Quoting myself: > It takes about half a second for mdadm to assemble my root array I didn't make any claim about any other timings, since I have not made any measurements (I am not adding instrumentation code to my initramfs and rebooting the box just to do this, and my watch is not precise enough to measure the time spent in initramfs). After the kernel has loaded, but before init on my root fs is run, there are only three things that cause noticeable delays: * probing all the disks. * assembling the root array. * mounting the root filesystem. -- Nick Bowler, Elliptic Technologies (http://www.elliptictech.com/) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: H. Peter Anvin on 17 Feb 2010 17:30
On 02/17/2010 10:46 AM, Volker Armin Hemmann wrote: > > well at the moment it takes less than two seconds until init takes over. > > Adding .5 seconds is a lot. And loading the initrd and changing root isn't > free either, true? > > I remember well all the noise in the past about making linux booting faster. > So why slow it down with an initrd - especially if you can do without? > Note that an extremely lightweight initramfs can quite possibly be faster than doing it in the kernel, just because userspace is so much less constrained. I was hoping klibc would catch on for this stuff, but it hasn't as much as I'd like. -hpa -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ |