lkml.org 
[lkml]   [2010]   [Feb]   [17]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: (boot time consequences of) Linux mdadm superblock question.
    On Wed, 17 Feb 2010 10:41:34 -0800 (PST)
    david@lang.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@lang.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


    \
     
     \ /
      Last update: 2010-02-18 00:27    [W:4.126 / U:0.160 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site