linux-kernel - Re: (boot time consequences of) Linux mdadm superblock question.

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Thu, 18 Feb 2010 10:24:07 +1100
From:	Neil Brown <neilb@...e.de>
To:	david@...g.hm
Cc:	Nick Bowler <nbowler@...iptictech.com>,
	Volker Armin Hemmann <volkerarmin@...glemail.com>,
	Kyle Moffett <kyle@...fetthome.net>,
	Rudy Zijlstra <rudy@...mpydevil.homelinux.org>,
	"Mr. James W. Laferriere" <babydr@...y-dragons.com>,
	Bill Davidsen <davidsen@....com>,
	Michael Evans <mjevans1983@...il.com>,
	linux-kernel@...r.kernel.org, linux-raid@...r.kernel.org
Subject: Re: (boot time consequences of) Linux mdadm superblock question.

On Wed, 17 Feb 2010 10:41:34 -0800 (PST)
david@...g.hm wrote:

> On Wed, 17 Feb 2010, Nick Bowler wrote:
> 
> > On 19:27 Wed 17 Feb     , Volker Armin Hemmann wrote:
> >> On Mittwoch 17 Februar 2010, Nick Bowler wrote:
> >>> On 09:41 Wed 17 Feb     , david@...g.hm wrote:
> >>>> for a distro that is trying to make one kernel image run on every
> >>>> possible type of hardware features like initramfs (and udev, modeules,
> >>>> etc) are wonderful.
> >>>>
> >>>> however for people who run systems that are known ahead of time and
> >>>> static (and who build their own kernels instead of just relying on the
> >>>> distro default kernel), all of this is unnessesary complication, which
> >>>> leaves more room for problems to creep in.
> >>>
> >>> Such people can easily construct an initramfs containing busybox and
> >>> mdadm with a shell script hardcoded to mount their root fs and run
> >>> switch_root.  It's a ~10 minute jobbie that only needs to be done once.
> >>
> >> and even better when you don't have to do that one time job at all.
> >
> > But people who are building their own kernels are already doing a
> > (much harder, imo) one time job of configuring their kernels.
> >
> >> btw, what about additional delay?
> >
> > 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.

It is worth noting that the Team that was recently working for v.short boot
times wanted to disable in-kernel autodetect for RAID, and added a
compile-time option to do just that.

The reason is that before the in-kernel autodetection can work reliably you
have to wait for all storage devices to have been discovered.  That wait
can unnecessarily increase the total boot time.

Using user-space autodetection, you can plug "mdadm -I" into udev, and have
arrays assembled as they are found, and filesystems mounted as arrays are
assembled, and then you just have to wait for the root filesystem to appear,
not for "all devices".

Yes, you could make the in-kernel autodetection smarter so it doesn't have to
wait quite so long, but that would make it quite a bit more complex, and it
is harder to maintain the complexity in the kernel.

NeilBrown
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/