Re: Linux mdadm superblock question.

[Kyle Moffett <kyle@moffetthome.net>]

On Wed, Feb 17, 2010 at 04:38, Rudy Zijlstra
<rudy@grumpydevil.homelinux.org> wrote:
> Kyle Moffett wrote:
>> On Tue, Feb 16, 2010 at 21:01, Neil Brown <neilb@suse.de> 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-raid" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html