From: Peter Rabbitson <rabbit+list@rabbit.us>
To: Tim Southerwood <ts@dionic.net>
Cc: linux-raid@vger.kernel.org
Subject: Re: [PATCH] Use new sb type
Date: Tue, 29 Jan 2008 10:37:12 +0100 [thread overview]
Message-ID: <479EF3C8.7010509@rabbit.us> (raw)
In-Reply-To: <479EA6DE.9070503@dionic.net>
Tim Southerwood wrote:
> David Greaves wrote:
>>
>> IIRC Doug Leford did some digging wrt lilo + grub and found that 1.1 and 1.2
>> wouldn't work with them. I'd have to review the thread though...
>>
>> David
>> -
>
> For what it's worth, that was my finding too. -e 0.9+1.0 are fine with
> GRUB, but 1.1 an 1.2 won't work under the filesystem that contains
> /boot, at least with GRUB 1.x (I haven't used LILO for some time nor
> have I tried the development GRUB 2).
>
> The reason IIRC boils down to the fact that GRUB 1 isn't MD aware, and
> the only reason one can "get away" with using it on a RAID 1 setup at
> all is that the constituent devices present the same data as the
> composite MD device, from the start.
>
> Putting an MD SB at/near the beginning of the device breaks this case
> and GRUB 1 doesn't know how to deal with it.
>
> Cheers
> Tim
> -
I read the entire thread, and it seems that the discussion drifted away from
the issue at hand. I hate flogging a dead horse, but here are my 2 cents:
First the summary:
* Currently LILO and GRUB are the only booting mechanisms widely available
(GRUB2 is nowhere to be seen, and seems to be badly designed anyway)
* Both of these boot mechanisms do not understand RAID at all, so they can
boot only off a block device containing a hackishly-readable filesystem (lilo:
files are mappable, grub: a stage1.5 exists)
* 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.
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
* 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.
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?
Cheers
Peter
next prev parent reply other threads:[~2008-01-29 9:37 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 [this message]
2008-01-29 11:25 ` Yes, but please provide the clue (was Re: [PATCH] Use new sb type) Moshe Yudkowsky
2008-01-28 19:10 ` [PATCH] Use new sb type 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=479EF3C8.7010509@rabbit.us \
--to=rabbit+list@rabbit.us \
--cc=linux-raid@vger.kernel.org \
--cc=ts@dionic.net \
/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).