linux-kernel - Re: 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: Windows password security audit tool. GUI, reports in PDF.

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

Date:	Sun, 14 Feb 2010 21:47:16 +0100
From:	Asdo <asdo@...ftmail.org>
To:	Henrique de Moraes Holschuh <hmh@....eng.br>
Cc:	Michael Evans <mjevans1983@...il.com>,
	Volker Armin Hemmann <volkerarmin@...glemail.com>,
	linux-kernel@...r.kernel.org, linux-raid@...r.kernel.org
Subject: Re: Linux mdadm superblock question.

Henrique de Moraes Holschuh wrote:
> On Sat, 13 Feb 2010, Michael Evans wrote:
>   
>> I remember hearing that 1.x had /no/ plans for kernel level
>> auto-detection ever.  That can be accomplished in early-userspace
>> leaving the code in the kernel much less complex, and therefore far
>> more reliable.
>>     
>
> Yes, it is far more reliable kernel side, if only because it doesn't do
> anything.
>
> But the userspace reliability is _not_ good.  initrds are a source of
> problems the moment things start to go wrong, and that's when they are not
> the problem themselves.
>
> And the end result is a system that needs manual intervention to get its
> root filesystem back.
>
> In my experience, every time we moved critical codepaths to userspace, we
> ended up decreasing the *overall* system reliability.
>   
I don't see it like this.
You have the same chance to screw up the system by making mistakes in 
the files in /etc, in the networking config, the firewall, the server 
applications...
(note: I speak for Debian/Ubuntu, redhat's initramfs I think is more messy.)
1.x autodetection worked great for me in initramfs. Basically you only 
need /etc/mdadm/mdadm.conf copied to initramfs (via update-initramfs), 
the rest is done by Debian/Ubuntu standard initramfs procedure.
Also consider 1.x allows to choose which arrays are autoassembled 
(hostname written in the array name equal to hostname in the machine or 
specified in mdadm.conf): this is more precise than 0.9 which 
autoassembles all, I think.
--
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/