From: Moshe Yudkowsky <moshe@pobox.com>
To: linux-raid@vger.kernel.org
Subject: Yes, but please provide the clue (was Re: [PATCH] Use new sb type)
Date: Tue, 29 Jan 2008 05:25:20 -0600 [thread overview]
Message-ID: <479F0D20.20306@pobox.com> (raw)
In-Reply-To: <479EF3C8.7010509@rabbit.us>
> * The only raid level providing unfettered access to the underlying
> filesystem is RAID1 with a superblock at its end, and it has been common
> wisdom for years that you need RAID1 boot partition in order to boot
> anything at all.
Ah. This shines light on my problem...
> The problem is that these three points do not affect any other raid
> level (as you can not boot from any of them in a reliable fashion
> anyway). I saw a number of voices that backward compatibility must be
> preserved. I don't see any need for that because:
>
> * The distro managers will definitely RTM and will adjust their flashy
> GUIs to do the right thing by explicitly supplying -e 1.0 for boot devices
The Debian stable distro won't let you create /boot on an LVM RAID1, but
that seems to be the extent of current RAID awareness. Using the GUI, if
you create a large RAID5 and attempt to boot off it -- well, you're
toast, but you don't find out until LILO and grub portion of the
installation fails.
> * A clueless user might burn himself by making a single root on a single
> raid1 device. But wait - he can burn himself the same way by making the
> root a raid5 device and rebooting.
Okay, but:
> Why do we sacrifice "the right thing to do"? To eliminate the
> possibility of someone shooting himself in the foot by not reading the
> manual?
Speaking for clueless users everywhere: I'd love to Read The Fine
Manual, but the Fine md, mdadm, and mdadm.conf Manuals that I've read
don't have information about grub/LILO issues. A hint such as "grub and
LILO can only work from RAID 1 and superblocks greater than 1.0 will
toast your system in any case" is crucial information to have. Not
everyone will catch this particular thread -- they're going to RTFM and
make a mistake *regardless*.
And now, please excuse me while I RTFM to find out if I change the
superblocks to 1.0 from 1.2 on a running array...
--
Moshe Yudkowsky * moshe@pobox.com * www.pobox.com/~moshe
"If you're not part of the solution, you're part of the process."
-- Mark A. Johnson
next prev parent reply other threads:[~2008-01-29 11:25 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-01-28 17:22 [PATCH] Use new sb type Jan Engelhardt
2008-01-28 18:19 ` David Greaves
2008-01-28 18:47 ` Peter Rabbitson
2008-01-28 19:32 ` David Greaves
2008-01-29 4:09 ` Tim Southerwood
2008-01-29 9:37 ` Peter Rabbitson
2008-01-29 11:25 ` Moshe Yudkowsky [this message]
2008-01-28 19:10 ` Jan Engelhardt
2008-01-29 23:08 ` Bill Davidsen
2008-01-30 12:53 ` David Greaves
2008-02-08 0:23 ` Jan Engelhardt
2008-02-10 10:34 ` David Greaves
2008-02-10 12:12 ` Jan Engelhardt
2008-02-10 12:27 ` David Greaves
2008-02-10 12:30 ` Jan Engelhardt
2008-02-11 3:32 ` Bill Davidsen
2008-02-11 8:21 ` David Greaves
2008-02-11 18:28 ` Bill Davidsen
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=479F0D20.20306@pobox.com \
--to=moshe@pobox.com \
--cc=linux-raid@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).