[Top][All Lists]

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

Re: grub RAID heuristics (how can we avoid "superfluous RAID member (2 f

From: Vladimir 'φ-coder/phcoder' Serbinenko
Subject: Re: grub RAID heuristics (how can we avoid "superfluous RAID member (2 found)")
Date: Thu, 23 Feb 2012 06:43:23 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:8.0) Gecko/20120216 Icedove/8.0

On 02.02.2012 01:55, Daniel Kahn Gillmor wrote:
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)
Try attached patch
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
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.



Grub-devel mailing list

Vladimir 'φ-coder/phcoder' Serbinenko

Attachment: filterguess.diff
Description: Text Data

reply via email to

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