[lkml]   [2010]   [Feb]   [17]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: Linux mdadm superblock question.
    On Tue, Feb 16, 2010 at 21:01, Neil Brown <> wrote:
    > On Tue, 16 Feb 2010 16:03:43 -0900 (AKST) "Mr. James W. Laferriere" <> wrote:
    >>       I am unaware of any record from Neil or other maintainer(s) of the
    >> /md/ device tree saying that they will not remove the 0.90 table and the
    >> autoassembly functions there .  I'd very much like to hear a statement saying
    >> there will not be a removal of the autoassembly functions for 0.90 raid table
    >> from the kernel tree .
    > I will not be removing 0.90 or auto-assemble from the kernel in the
    > foreseeable future.
    > None the less, I recommend weaning yourself from your dependence on it.
    > initramfs is the future, embrace it.

    What are people's reasons for pushback against initramfs? I've heard
    lots of claims that "it's not trustworthy" and "it breaks", but in 7
    years of running bootable software RAID boxes on weird architectures
    (even running Debian unstable) I have only once or twice had initramfs

    As a software capability, initramfs makes it possible to use
    *anything* as a root filesystem, no matter what is necessary to set it
    up. For example, I have seen somebody use DRBD (essentially network
    RAID-1) as a root filesystem with a few custom hook scripts added to
    the initramfs-tools configs. Other examples include using Sun ZFS as
    a root fs via an initramfs FUSE daemon, a feat which even Solaris
    could not accomplish at the time. Encrypted root filesystems also
    require an initramfs to prompt for encryption keys and decrypt the
    block device. Multipath block devices are another example.

    You should also take a look at your distro installers. There is not a
    single one made in the last several years which does not use an
    initramfs to start networking or access the installation media. In
    fact, of all the distro installers I have had the most consistent
    behavior regardless of system hardware from the ones which operate
    entirely out of their initramfs.

    From a reliability perspective, an initramfs is no more essential
    than, say, /sbin/init or /boot/vmlinuz-2.6.33. Furthermore, all of
    the modern initramfs generation tools automatically keep backup copies
    exactly the same way that "make install" keeps backup copies of your
    kernel images. The two times I've managed to hose my initramfs I was
    able to simply edit my grub config to use a file called something like
    "/boot/initramfs-2.6.33.bak" instead.

    In fact, I have had several times where an initramfs made my boot
    process *more* reliable. On one of my LVM JBOD systems, I was able to
    pull a group of 3 SATA drives whose backplane had failed and drop them
    all in USB enclosures to get the system back up and running in a half
    an hour. With just straight partitions on the volumes I would have
    been hunting around for 2 hours to figure out where all my partitions
    had gone only to have the USB drives spin up in a different order
    during the next reboot.

    If you're really concerned about boot-process reliability, go ahead
    and tell your initramfs tool to include a fully-featured busybox,
    coreutils, bash, strace, gdb, and a half-dozen other developer tools.
    You may wait an extra 20 seconds for your bootloader to load the damn
    thing during boot, but you'll be able to track down that annoying
    10-second hang in your /sbin/init program during config-file parsing.

    I've built specialized embedded computers with stripped-down chipset
    initialization code, a tiny Linux kernel and a special-purpose
    initramfs burned into the flash. By using the fastboot patches and
    disabling all the excess drivers, my kernel was fully operational
    within the first half-second. It used the tools on the initramfs to
    poke around on the hard disk as a bootloader, then kexec() to load the
    operational kernel.

    Counting up all the problems I've had with system boot... I've had an
    order of magnitude more problems from somebody getting careless with
    "rm", "dpkg --purge", etc than with initramfs deficiencies.

    Kyle Moffett
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2010-02-17 07:37    [W:0.024 / U:13.020 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site