Re: Software RAID and Fakeraid

[Vladimir 'φ-coder/phcoder' Serbinenko]

On 12/04/2010 05:34 AM, Leslie Rhorer wrote:
>
>   
>> -----Original Message-----
>> From: address@hidden [mailto:linux-raid-
>> address@hidden On Behalf Of Neil Brown
>> Sent: Tuesday, November 30, 2010 4:25 PM
>> To: Phillip Susi
>> Cc: The development of GNU GRUB; John Sheu; address@hidden
>> Subject: Re: Software RAID and Fakeraid
>>
>> On Tue, 30 Nov 2010 14:54:40 -0500 Phillip Susi <address@hidden> wrote:
>>
>>     
>>> On 11/25/2010 5:26 AM, John Sheu wrote:
>>>       
>>>> What's the preferred way to differentiate BIOS fakeraid from regular
>>>> software mdraid?
>>>>         
>>> The only way I know of is detecting that it is a dmraid device as
>>> opposed to md, which is why grub does it that way.  This worked well in
>>> the past when each tool exclusively handled one type of raid.
>>>
>>>       
>>>> I ask this as I'm booting with GRUB2 off a system that has one of
>>>>         
>> those
>>     
>>>> Intel fakeraid chipsets.  As of a few months ago, the mdadm package
>>>>         
>> has
>>     
>>>> supported these fakeraid setups, so the RAID array comes up as a
>>>>         
>> /dev/md###
>>     
>>>> device.  This is unfortunate, as GRUB2 assumes that any device of the
>>>>         
>> type
>>     
>>>> /dev/md### must be a pure software RAID device, and in
>>>> util/grub-setup.c:939, tries to install itself to the RAID members
>>>> individually:
>>>>         
>>> For grub to support fakeraids activated by the md driver, it needs some
>>> way to find out that it is actually a fake raid, and not a software
>>> raid.  Adding linux-raid to Cc list to see if they can suggest a way of
>>> doing that.
>>>       
>> My feeling is that grub just needs to be a bit more careful.
>>
>> If the members of the md array are partitions, then installing itself in
>> the
>> boot blocks of the devices holding those partitions always makes sense.
>>
>> If the members of the md array are whole devices, then installing grub in
>> those devices might make sense depending on specific details of the
>> metadata.  The default should be that it doesn't make sense, but specific
>> cases do.
>> e.g. if the metadata (/sys/block/mdX/md/metadata_version) is 0.90 or 1.0,
>> and
>> the array is RAID1, then grub should install itself in the *array*, not in
>> the devices.
>> If the metadata is 1.1, then grub cannot install itself
>> If the metadata is 1.2, then grub can install itself at the start
>> If the metadata is external:imsm then (I think) grub should install itself
>> in
>> the array ... though there are some complexities there.
>>
>> I often wonder why people who add knowledge of md to grub etc don't at
>> least
>> let me know what they are doing in case I can see something obviously
>> wrong
>> with their approach..
>>     
>       I wonder why GRUB2 only supports 0.90 version superblocks on arrays
> from which it can boot.  I wonder even more why they seem to keep it a deep,
> dark secret.  I tore my hair out for days trying to figure out why my
> upgraded Linux box would not boot.  Under legacy GRUB, it took some
> fiddling, but 1.x RAID1 arrays were bootable.
>
>
>   
1.x metadata was added this summer. Please upgrade
> _______________________________________________
> Grub-devel mailing list
> address@hidden
> http://lists.gnu.org/mailman/listinfo/grub-devel
>
>   


-- 
Regards
Vladimir 'φ-coder/phcoder' Serbinenko

signature.asc
Description: OpenPGP digital signature