Thank you Pierre,
This may help me. I've got an array of 6. I moved disks from one
chassis to another and at that time, one of the disks dropped out of the
array. I modified the partition table of sde, as the new system called
it, since its partition table was blank.
Once I made the partition table the same as all other drives in the
array and ran mdadm -a /dev/md0 /dev/sde2, /proc/mdstat indicated that
it was re-building the array. It took a day and a half or so and it
looked like it was going to complete before I woke up in the morning, so
I went to sleep when it was at 98.8% with 300m left in the prepare at
current rate.
I was doing a 500G copy at the time, so the long duration to complete
1.2% seemed reasonable to me.
When I woke up in the morning, the array showed _UUUU_, with sde and sdg
now having fallen out of the array. I have since shut the array down
and want some advice for how to move forward. I've got 5 new 1T disks
in the mail, and they should probably arrive today. I've got a sixth
here on my desk, but it has some of the data that was potentially lost,
so I don't really want to use it in the new array. I'll set it up as a
spare once the recovery is complete.
So, considering that I've got enough storage to duplicate the current
state of the disks at a block level, can you advise me on next steps?
Mine look like this:
1) wait until new drives arrive
2) dd if=/dev/sd$old of=/dev/sd$new
3) ???
4) profit!
Cheers,
C.J.
On Sat, 2012-05-12 at 19:19 +0200, Pierre Beck wrote:
> Hi,
>
> got an all-spares auto-assembly on IRC with "Raid level: -unknown-". We
> recovered by re-creating the array. Since more data is always good, I
> add this to the thread and hope it helps confirm the bug is fixed by the
> patch.
>
> RAID-5, 3 members with 1 missing on creation and ever since.
>
> Members on partitions with partition type set for auto-assembly.
>
> Array was transported to a new machine.
>
> Drive order got mixed up on transport: AB_ BA_
> (figured that out on recovery)
>
> On target machine boot-up (array not yet configured in mdadm.conf)
> Archlinux auto-assembled array with both drives as spares:
>
> /dev/sda1:
> Magic : a92b4efc
> Version : 1.2
> Feature Map : 0x0
> Array UUID : c051172d:52ed3e47:e8dc6dc8:8798f4c9
> Name : OncleGeorges:0
> Creation Time : Fri Aug 5 18:00:19 2011
> Raid Level : -unknown-
> Raid Devices : 0
>
> Avail Dev Size : 1953515969 (931.51 GiB 1000.20 GB)
> Data Offset : 2048 sectors
> Super Offset : 8 sectors
> State : active
> Device UUID : a8b44e10:ff04d973:c5f92933:3c9e124f
>
> Update Time : Sat Apr 21 19:14:34 2012
> Checksum : 8b57fb27 - correct
> Events : 1
>
>
> Device Role : spare
> Array State : ('A' == active, '.' == missing)
>
> /dev/sdb1:
> Magic : a92b4efc
> Version : 1.2
> Feature Map : 0x0
> Array UUID : c051172d:52ed3e47:e8dc6dc8:8798f4c9
> Name : OncleGeorges:0
> Creation Time : Fri Aug 5 18:00:19 2011
> Raid Level : -unknown-
> Raid Devices : 0
>
> Avail Dev Size : 2046769231 (975.98 GiB 1047.95 GB)
> Used Dev Size : 1953515969 (931.51 GiB 1000.20 GB)
> Data Offset : 2048 sectors
> Super Offset : 8 sectors
> State : active
> Device UUID : d2594375:c8adc5a0:53938a24:9bd5c6be
>
> Update Time : Sat Apr 21 19:14:34 2012
> Checksum : 83dd0895 - correct
> Events : 1
>
>
> Device Role : spare
> Array State : ('A' == active, '.' == missing)
>
>
> Versions:
>
> Linux HostName 3.3.4-2-ARCH #1 SMP PREEMPT Wed May 2 15:39:58 UTC 2012
> i686 AMD Athlon(tm) 64 X2 Dual Core Processor 3800+ AuthenticAMD GNU/Linux
>
> mdadm - v3.2.3 - 23rd December 2011
>
> Greetings,
>
> Pierre Beck
> --
> 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
Attachment:
signature.asc
Description: This is a digitally signed message part
