[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

grub RAID heuristics (how can we avoid "superfluous RAID member (2 found

From: Daniel Kahn Gillmor
Subject: grub RAID heuristics (how can we avoid "superfluous RAID member (2 found)")
Date: Wed, 01 Feb 2012 19:55:19 -0500
User-agent: Mozilla/5.0 (X11; Linux i686; rv:9.0) Gecko/20120125 Icedove/9.0.1

hi folks--

i was speaking with phcoder today on #grub, about getting messages like
this from grub when a partition that is part of a Linux SW RAID set
(with metadata 0.9x) is close to the end of its containing block device:

  superfluous RAID member (2 found)

Here's phcoder's explanation of the problem:

> 16:08 < phcoder> if you have < 64KiB between end of disk and end of partition 
>                  the metadata is exactly in the same place for either if the 
>                  whole disks are raided or only partitions. And no field 
> which 
>                  allows to distinguish those
> 16:09 < phcoder> thing is that mdraid format rounds it down to a 64K aligned 
>                  boundary
> 16:10 < dkg0> 64KiB aligned to the parent disk, or to the partition itself?
> 16:10 < phcoder> to whatever the host of the raid is. For your error to occur 
>                  it has to be both
> 16:10 < dkg0> hm, i suppose if the partition itself starts evenly aligned 
> with 
>               a 64KiB boundary, it'd be the same thing.

It sounds like there might be some circumstances (e.g. a RAID0 set of
sda and sdb, creating md0, and a partition table on top of md0) where it
is legitimately difficult to decide the correct interpretation.

However, i think there might be a reasonable heuristic that can be used
in the case of RAID1 sets that would avoid the ambiguity (and the scary
messages/warnings to the user:

Select the smallest known block device that can completely enclose the
RAID member.  The larger block device(s) should not be considered to be
exporting that RAID.

these heuristics would mean that RAID1 sets with 0.9x metadata on any
sort of disklabel would only have their member components show up once
during a scan, rather than treating them as a duplicate.

phcoder mentioned that the RAID code was undergoing something of an
overhaul.  perhaps these heuristics could play into that update?

I'm not sure how to address it with RAID0 or RAID10, but if we could fix
the RAID1 case, that would be a big win for a lot of users.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]