Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752243Ab0BQQYU (ORCPT ); Wed, 17 Feb 2010 11:24:20 -0500 Received: from mail-iw0-f185.google.com ([209.85.223.185]:46063 "EHLO mail-iw0-f185.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751450Ab0BQQYS convert rfc822-to-8bit (ORCPT ); Wed, 17 Feb 2010 11:24:18 -0500 MIME-Version: 1.0 In-Reply-To: <4B7BB927.5000305@grumpydevil.homelinux.org> References: <201002140251.59668.volkerarmin@googlemail.com> <4877c76c1002132002s20d942c3i7cee5418cdcf369c@mail.gmail.com> <201002141940.35716.volkerarmin@googlemail.com> <4B7AD35E.7000405@tmr.com> <20100217130103.3ca65ef3@notabene.brown> <4B7BB927.5000305@grumpydevil.homelinux.org> From: Kyle Moffett Date: Wed, 17 Feb 2010 11:22:45 -0500 Message-ID: Subject: Re: Linux mdadm superblock question. To: Rudy Zijlstra Cc: Neil Brown , "Mr. James W. Laferriere" , Bill Davidsen , Volker Armin Hemmann , Michael Evans , linux-kernel@vger.kernel.org, linux-raid@vger.kernel.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8BIT Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 5120 Lines: 101 On Wed, Feb 17, 2010 at 04:38, Rudy Zijlstra wrote: > Kyle Moffett wrote: >> On Tue, Feb 16, 2010 at 21:01, Neil Brown wrote: >>> 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 >> problems. >> >> 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. > > We are looking at 2 different use-cases i think. > > for the power-user system manager, who manages all his servers and has > knowledgeable backup, initrd may indeed work as above. > > I have to keep in mind, that when there is a problem while i am travelling > (and that happens), there is no sys-admin present. Also, i am supporting > systems remote where no-one has the knowledge to debug using a initrd. In > such cases, initrd is an additional step. And each additional step is an > additional source of mistakes. Actually, a properly built initramfs gives you far more reliable behavior even without a local sysadmin. For example, most graphical-boot tools are designed to be built into an initramfs; I have seen some prototype initramfs images which provide end-user accessible GUI boot menus and other tools which function reliably even when your root filesystem is inaccessible. > 1/ distro tools assume that the kernel being build will run on that machine. > For servers this is often not true. There are very valid security reasons to > exclude compilation capability from many servers. As Frans Pop states, this is entirely untrue for (at the very least) Debian. The "initramfs-tools" package present there works regardless of where I obtain my kernel. If I use the "make-kpkg" Debian tool when building my kernel (regardless of where it is built), then the resulting package will automatically generate an appropriate initramfs image when installed. If for some reason I install a kernel by hand I can very trivially build the necessary initramfs with this command: update-initramfs -c -k 2.6.32-mykernel01 In the event that you need to "customize" the initramfs for some reason, you can simply do so. When the "update-initramfs" tool is next run, it will report that the user has customized that image and avoid modifying it. If you wish to return to the autogenerated initramfs you can simply run this command: update-initramfs -u -t -k 2.6.32-2-amd64 > 2/ For most small shops, there is need for RAID (disks are fallible, shop > cannot do without server), the RAID should work without being visible. If > there is a problem with the RAID that causes auto-assemble to break, it > means i need to travel (>100KM) to trouble shoot. The simpler the setup, the > more i like it. This is also why i almost always use HW raid for the system > partitions. The ones i use have userland tools in Linux which warn on disk > failure, ensure auto rebuild, etc... > Still, for large storage needs it is SW RAID over SATA. > > 3/ for my home systems, if i need to remote-support to get things working > again (i am often travelling for my work), the added layer of initrd is an > added layer of possible mistakes. You are actually just setting yourself up for problems. RAID autoassembly has bad corner cases when disks disappear between reboots (which happens with failing disk head assemblies). In that case it will fail to find its root filesystem or wait forever for the last disk to show up. I have had even *worse* problems (including corruption of unrelated logical volumes) with many hardware RAID controllers, even those from big-name server vendors such as HP and Dell. To contrast, an initramfs is configurable to prompt the user, automatically degrade the array after a small delay, or even play a kazoo if desired :-D. One of these days I may get around to building myself a small GUI wrapper around mdadm on an initramfs which allows a user to manually recover from RAID problems. Cheers, Kyle Moffett -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/