From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from list by lists.gnu.org with archive (Exim 4.71) id 1S0RSr-0002dC-KY for mharc-grub-devel@gnu.org; Thu, 23 Feb 2012 00:43:37 -0500 Received: from eggs.gnu.org ([140.186.70.92]:51518) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1S0RSn-0002bF-IY for grub-devel@gnu.org; Thu, 23 Feb 2012 00:43:35 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1S0RSm-0000DE-8C for grub-devel@gnu.org; Thu, 23 Feb 2012 00:43:33 -0500 Received: from mail-ey0-f169.google.com ([209.85.215.169]:39860) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1S0RSl-0000Cy-WD for grub-devel@gnu.org; Thu, 23 Feb 2012 00:43:32 -0500 Received: by eaag11 with SMTP id g11so337609eaa.0 for ; Wed, 22 Feb 2012 21:43:31 -0800 (PST) Received-SPF: pass (google.com: domain of phcoder@gmail.com designates 10.213.22.133 as permitted sender) client-ip=10.213.22.133; Authentication-Results: mr.google.com; spf=pass (google.com: domain of phcoder@gmail.com designates 10.213.22.133 as permitted sender) smtp.mail=phcoder@gmail.com; dkim=pass header.i=phcoder@gmail.com Received: from mr.google.com ([10.213.22.133]) by 10.213.22.133 with SMTP id n5mr192875ebb.26.1329975811163 (num_hops = 1); Wed, 22 Feb 2012 21:43:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type; bh=JNT03xYoaOUam5upJ6/8qb6iXPB6I1CqxOmMsqOpW8c=; b=igTrraG9FcQuJahzl9ESaJX46cnH9/BCWTBTVayLhVNIFaXjkPuoYnx5I/r+4/n0I4 iC+myNkQYe4XU7I1MM5q/fKRLUZ68OzyYAMUdje6gihqZSYd4jZxRJ7Q7M/o8a0Ak6ln tak0kEw9qNW570NTq3GkK8t+lUEQF4OkRw6o0= Received: by 10.213.22.133 with SMTP id n5mr151035ebb.26.1329975810918; Wed, 22 Feb 2012 21:43:30 -0800 (PST) Received: from debian.x201.phnet (1-234.197-178.cust.bluewin.ch. [178.197.234.1]) by mx.google.com with ESMTPS id n56sm1344637eeh.6.2012.02.22.21.43.28 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 22 Feb 2012 21:43:29 -0800 (PST) Message-ID: <4F45D1FB.2070205@gmail.com> Date: Thu, 23 Feb 2012 06:43:23 +0100 From: =?UTF-8?B?VmxhZGltaXIgJ8+GLWNvZGVyL3BoY29kZXInIFNlcmJpbmVua28=?= User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:8.0) Gecko/20120216 Icedove/8.0 MIME-Version: 1.0 To: grub-devel@gnu.org Subject: Re: grub RAID heuristics (how can we avoid "superfluous RAID member (2 found)") References: <4F29DEF7.80009@fifthhorseman.net> In-Reply-To: <4F29DEF7.80009@fifthhorseman.net> Content-Type: multipart/mixed; boundary="------------030703060308030002020800" X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 209.85.215.169 X-BeenThere: grub-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: The development of GNU GRUB List-Id: The development of GNU GRUB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Feb 2012 05:43:35 -0000 This is a multi-part message in MIME format. --------------030703060308030002020800 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit 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 >> 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. > > Regards, > > --dkg > > _______________________________________________ > Grub-devel mailing list > Grub-devel@gnu.org > https://lists.gnu.org/mailman/listinfo/grub-devel > -- Regards Vladimir 'φ-coder/phcoder' Serbinenko --------------030703060308030002020800 Content-Type: text/x-diff; name="filterguess.diff" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="filterguess.diff" === modified file 'grub-core/disk/diskfilter.c' --- grub-core/disk/diskfilter.c 2012-02-12 14:25:25 +0000 +++ grub-core/disk/diskfilter.c 2012-02-23 05:42:14 +0000 @@ -972,35 +972,40 @@ : (pv->id.id == id->id)) { struct grub_diskfilter_lv *lv; + grub_disk_t disk; /* FIXME: Check whether the update time of the superblocks are the same. */ + disk = grub_disk_open (disk->name); + if (!disk) + return grub_errno; + if (disk && pv->disk && grub_disk_get_size (disk) >= pv->part_size) + { + grub_disk_close (disk); + return GRUB_ERR_NONE; + } + pv->disk = disk; /* This could happen to LVM on RAID, pv->disk points to the raid device, we shouldn't change it. */ - if (! pv->disk) - { - pv->disk = grub_disk_open (disk->name); - if (! pv->disk) - return grub_errno; - pv->part_start = grub_partition_get_start (disk->partition); - pv->part_size = grub_disk_get_size (disk); + pv->start_sector -= pv->part_start; + pv->part_start = grub_partition_get_start (disk->partition); + pv->part_size = grub_disk_get_size (disk); #ifdef GRUB_UTIL - { - grub_size_t s = 1; - grub_partition_t p; - for (p = disk->partition; p; p = p->parent) - s++; - pv->partmaps = xmalloc (s * sizeof (pv->partmaps[0])); - s = 0; - for (p = disk->partition; p; p = p->parent) - pv->partmaps[s++] = xstrdup (p->partmap->name); - pv->partmaps[s++] = 0; - } + { + grub_size_t s = 1; + grub_partition_t p; + for (p = disk->partition; p; p = p->parent) + s++; + pv->partmaps = xmalloc (s * sizeof (pv->partmaps[0])); + s = 0; + for (p = disk->partition; p; p = p->parent) + pv->partmaps[s++] = xstrdup (p->partmap->name); + pv->partmaps[s++] = 0; + } #endif - if (start_sector != (grub_uint64_t)-1) - pv->start_sector = start_sector; - pv->start_sector += pv->part_start; - } + if (start_sector != (grub_uint64_t)-1) + pv->start_sector = start_sector; + pv->start_sector += pv->part_start; /* Add the device to the array. */ for (lv = array->lvs; lv; lv = lv->next) if (!lv->became_readable_at && lv->fullname && is_lv_readable (lv)) --------------030703060308030002020800--