> >> > a new HDD has failed on me during a scrub.... i tried to remove/fail
> it
> >> but
> >> > it kept saying the device was busy. so i forced a reboot.
BTW, it's better, if you can, to free up the device, rather than
reboot. Now that you have rebooted, that's no longer possible.
> >> > I have physically disconnected the drive..
> >> >
> >> > can anyone take alook at the examine below and tell me if it is
> should
> >> > assemble ok?
> >> >
> >> > I tried
> >> >
> >> > mdadm --assemble /dev/md4 /dev/sda1 /dev/sdb1 /dev/sdd1 /dev/sde1
> >> /dev/sdf1
> >> > /dev/sdg1
> >>
> >> I'd try:
> >>
> >> mdadm --assemble /dev/md4 /dev/sd{g,a,e}1 missing /dev/sd{d,b,f}1
> >
> >
> > Yeah, I would, too. Also, what are the contents of
> > /etc/mdadm/mdadm.conf? If it is correct, then `mdadm --assemble --scan`
> > should work.
> >
> >
>
> Hey, yeah I am confused as drives have failed before and it has still
> assembled. I think it is because it is unclean....
>
> Can I ask how did you arrive at the command list?
Look at the results of --examine. Every one shows the list of
drives and their order.
> what is wrong with dbf?
'No idea. SMART might give you an idea, or the kernel logs.
> also this is my mdadm.conf
>
>
> DEVICE /dev/sd[abcdefg]1 /dev/hd[ab]1
>
> ARRAY /dev/md/4 metadata=0.90 UUID=7438efd1:9e6ca2b5:d6b88274:7003b1d3
> ARRAY /dev/md/3 metadata=0.90 UUID=a1f24bc9:4e72a820:3a03f7dc:07f9ab98
> ARRAY /dev/md/2 metadata=0.90 UUID=0642323a:938992ef:b750ab21:e5a55662
> ARRAY /dev/md/1 metadata=0.90 UUID=d4eeec62:148b3425:3f5e931c:bb3ef499
--scan may work. I suggest updating the file with all the array
members. Why are all the arrays assembled with 0.90 superblocks? The 0.90
superblock has some significant limitations. They may not be causing you
grief right now, but they could in the future. The only arrays I have built
with 0.90 superblocks are the /boot targets, because GRUB2 does not support
1.x superblocks. I've chosen 1.2 for all the others.
--
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
