On Mon, Feb 14, 2011 at 5:20 PM, NeilBrown <neilb@xxxxxxx> wrote:
> On Mon, 14 Feb 2011 17:08:45 -0600 Mark Keisler <grimm26@xxxxxxxxx> wrote:
>
>> On Mon, Feb 14, 2011 at 4:48 PM, NeilBrown <neilb@xxxxxxx> wrote:
>> > On Mon, 14 Feb 2011 14:33:03 -0600 Mark Keisler <grimm26@xxxxxxxxx> wrote:
>> >
>> >> Sorry for the double-post on the original.
>> >> I realize that I also left out the fact that I rebooted since drive 0
>> >> also reported a fault and mdadm won't start the array at all. I'm not
>> >> sure how to tell which members were the in two RAID0 groups. I would
>> >> think that if I have a RAID0 pair left from the RAID10, I should be
>> >> able to recover somehow. Not sure if that was drive 0 and 2, 1 and 3
>> >> or 0 and 1, 2 and 3.
>> >>
>> >> Anyway, the drives do still show the correct array UUID when queried
>> >> with mdadm -E, but they disagree about the state of the array:
>> >> # mdadm -E /dev/sdb1 /dev/sdc1 /dev/sdd1 /dev/sde1 | grep 'Array State'
>> >> Array State : AAAA ('A' == active, '.' == missing)
>> >> Array State : .AAA ('A' == active, '.' == missing)
>> >> Array State : ..AA ('A' == active, '.' == missing)
>> >> Array State : ..AA ('A' == active, '.' == missing)
>> >>
>> >> sdc still shows a recovery offset, too:
>> >>
>> >> /dev/sdb1:
>> >> Data Offset : 2048 sectors
>> >> Super Offset : 8 sectors
>> >> /dev/sdc1:
>> >> Data Offset : 2048 sectors
>> >> Super Offset : 8 sectors
>> >> Recovery Offset : 2 sectors
>> >> /dev/sdd1:
>> >> Data Offset : 2048 sectors
>> >> Super Offset : 8 sectors
>> >> /dev/sde1:
>> >> Data Offset : 2048 sectors
>> >> Super Offset : 8 sectors
>> >>
>> >> I did some searching on the "READ FPDMA QUEUED" error message that my
>> >> drive was reporting and have found that there seems to be a
>> >> correlation between that and having AHCI (NCQ in particular) enabled.
>> >> I've now set my BIOS back to Native IDE (which was the default anyway)
>> >> instead of AHCI for the SATA setting. I'm hoping that was the issue.
>> >>
>> >> Still wondering if there is some magic to be done to get at my data again :)
>> >
>> > No need for magic here .. but you better stand back, as
>> > I'm going to try ... Science.
>> > (or is that Engineering...)
>> >
>> > mdadm -S /dev/md0
>> > mdadm -C /dev/md0 -l10 -n4 -c256 missing /dev/sdc1 /dev/sdd1 /dev/sde1
>> > mdadm --wait /dev/md0
>> > mdadm /dev/md0 --add /dev/sdb1
>> >
>> > (but be really sure that the devices really are working before you try this).
>> >
>> > BTW, for a near=2, Raid-disks=4 arrangement, the first and second devices
>> > contain the same data, and the third and fourth devices also container the
>> > same data as each other (but obviously different to the first and second).
>> >
>> > NeilBrown
>> >
>> >
>> Ah, that's the kind of info that I was looking for. So, the third and
>> fourth disks are a complete RAID0 set and the entire RAID10 should be
>> able to rebuild from them if I replace the first two disks with new
>> ones (hence being sure the devices are working)? Or I need to hope
>> the originals will hold up to a rebuild?
>
> No.
>
> third and fourth are like a RAID1 set, not a RAID0 set.
>
> First and second are a RAID1 pair. Third and fourth are a RAID1 pair.
>
> First and third
> first and fourth
> second and third
> second and fourth
>
> can each be seen as a RAID0 pair which container all of the data.
>
> NeilBrown
>
>
>
>>
>> Thanks for the info, Neil, and all your work in FOSS :)
>
>
Oh, duh, was thinking in 0+1 instead of 10. I'm still wondering why
you made mention of "but be really sure that the devices really are
working before you try this." If trying to bring the RAID back fails,
I'm just back to not having access to the data which is where I am now
:).
--
To unsubscribe from this list: send the line "unsubscribe linux-raid" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
