[Top][All Lists]

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

Re: Raid5 regression

From: Goswin von Brederlow
Subject: Re: Raid5 regression
Date: Wed, 04 May 2011 21:01:48 +0200
User-agent: Gnus/5.110009 (No Gnus v0.9) XEmacs/21.4.22 (linux, no MULE)

Phillip Susi <address@hidden> writes:

> On 5/4/2011 11:21 AM, Vladimir 'φ-coder/phcoder' Serbinenko wrote:
>> Does it happen with grub-fstest ? Some BIOSes are known to chop away
>> some sectors in the end of disk.
> That seems to be what is going on.  I went back to the Maverick
> version of grub and it gets no complaints, until I set debug=raid.
> Then I can see the same type of messages about the duplicate detection.
> Comparing the two versions of raid.c, it looks like the old version
> just made the debug print when it found the duplicate superblock, and
> then carried on, replacing the previously found device.  The new
> version of insert_array() returns a grub_error().
> So the net result is that even though it always was detecting the
> superblock on both the whole disk and on the partition, it used to let
> the one found on the partition supersede so everything worked, but now
> it keeps the one on the whole disk and so things break.
> How should this conflict be resolved?  I would think that the
> partition should take precedence like it used to.

Unless the raid is partitioned and then the reverse is needed.


reply via email to

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