Re: 2+ raid sets, sata and a missing hd question
On Wed, Feb 15, 2006 at 01:45:21PM +1100, CaT wrote: Seeing as how SATA drives can move around if one removes one from a set (ie given sda, sdb, sdc, if sdb was removed sdc drops to sdb) would md6 come back up without problems if I were to remove either sda or sdb. if you configured mdadm correctly, you will have no problem :) hint echo DEVICE partitions >> /etc/mdadm.conf mdadm -Esc partitions | grep ARRAY>> /etc/mdadm.conf All md partitions are of type fd (Linux raid autodetect). this is surprisingly not at all relevant L. -- Luca Berra -- [EMAIL PROTECTED] Communication Media & Services S.r.l. /"\ \ / ASCII RIBBON CAMPAIGN XAGAINST HTML MAIL / \ - To unsubscribe from this list: send the line "unsubscribe linux-raid" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: RAID 5 inaccessible - continued
Krekna Mektek wrote: >I want to rebuilt from the good one and the faulty one. That's why I >wanted to dd the disk to an image file, but it complains it has no >boot sector. > > > I did the folowing: dd conv=noerror if=dev/hdd1 of=/mnt/hdb1/Faulty-RAIDDisk.img losetup /dev/loop0 /mnt/hdb1/Faulty-RAIDDisk.img You could try doing this again using ddrescue (google if you need to install it): ddrescue dev/hdd1 /mnt/hdb1/Faulty-RAIDDisk.img /mnt/hdb1/Faulty-RAIDDisk.log Then do it again using -r10 (to increase the retries on the faulty sectors) ddrescue -r10 dev/hdd1 /mnt/hdb1/Faulty-RAIDDisk.img /mnt/hdb1/Faulty-RAIDDisk.log This will be much quicker because the log file contains details of the faulty sectors. With luck (mucho luck) you may not even lose data. David -- - To unsubscribe from this list: send the line "unsubscribe linux-raid" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: RAID 5 inaccessible - continued
2006/2/14, Mike Hardy <[EMAIL PROTECTED]>: > > > Krekna Mektek wrote: > > > The dd actually succeeded, and did finish the job in about one day. > > The badblocks were found after about the first 7 Gigs. > > Is this a 3-disk raid5 array? With two healthy disks and one bad disk? Hi Mike! It is a 3 disk array, that is one spare (which was set as spare by Linux, previously marked as faulty I guess. This disk is probably out of date, because I don't know when this did happen, and I don't have the logs anymore). One disk is okay, and the faulty is probably also okay, except for the 76 bad sectors. I want to rebuilt from the good one and the faulty one. That's why I wanted to dd the disk to an image file, but it complains it has no boot sector. In this case, I actually *can* try the 2.6.15+ kernel then? Because the rebuilt *IS* working, except for the fact that it stops at 1,7%, which happens to be at the bad block area indeed. So, there actually IS a possibility now I was requesting for: mdadm to skip over the bad blocks area? That mean I can try again, but now with 2.6.15? And if not. I still don't understand why this did not work: > > > I did the folowing: > > > > > > dd conv=noerror if=dev/hdd1 of=/mnt/hdb1/Faulty-RAIDDisk.img > > > losetup /dev/loop0 /mnt/hdb1/Faulty-RAIDDisk.img > .. > > > > > > But it did not work out (yet). > > > > > > madm -E /dev/loop0 > > > mdadm: No super block found on /dev/loop0 (Expected magic a92b4efc, > > > got ) Thanks for your help! Krekna > > If so, then what you really want is a new kernel (2.6.15+? 2.6.14+?) > that has raid5 read-error-handling code in it. Neil just coded that up. > > If it's missing a disk and has a disk with bad sectors, then you've > already lost data, but you could use a combination of smart tests and dd > to zero out those specific sectors (and only those sectors...) then sync > a new disk up with the array... > > -Mike > - To unsubscribe from this list: send the line "unsubscribe linux-raid" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: RAID 5 inaccessible - continued
2006/2/14, Neil Brown <[EMAIL PROTECTED]>: > On Tuesday February 14, [EMAIL PROTECTED] wrote: > > Krekna is crying out loud in the empty wilderness > > No one there to help me? > > Nope :-) > > > > I did the folowing: > > > > > > dd conv=noerror if=dev/hdd1 of=/mnt/hdb1/Faulty-RAIDDisk.img > > > losetup /dev/loop0 /mnt/hdb1/Faulty-RAIDDisk.img > .. > > > > > > But it did not work out (yet). > > > > > > madm -E /dev/loop0 > > > mdadm: No super block found on /dev/loop0 (Expected magic a92b4efc, > > > got ) > ... > > > > > > - can I restore the superblock from the hdd1 disk (which is still alive) > > > > > If mdadm -E /dev/hdd1 shows a valid superblock, and mdadm -E > /dev/loop0 doesn't, then your 'dd' wasn't very successful. Hi, Actually, /dev/hdd1 partition is 390708801 blocks, the disk itself is a Hitachi 400GB disk. So this is 390708801 blocks of 1024 bytes. This is according to my calculation 400085812224 bytes. The Faulty-RAIDDisk.img is according to my ls -l 400085771264 bytes. So it looks like they are quite the same, and the difference between the two is 40960 bytes. These are 40 blocks, so 36 are missing? The dd actually succeeded, and did finish the job in about one day. The badblocks were found after about the first 7 Gigs. Is there no way like the conv=noerror for mdadm, to just continue? Can I restore the superblock on the .img file somehow? Is it probably save to --zero-superblock all the three disks and that the RAID array will create two new superblocks (Leaving the spare out, because its probably out of date). I can do the dd again, but I think it will do the same thing, because it finished 'succesfully'. The superblock is at the end of the disk I read, about the last 64-128K or something. Krekna > > What is the size of /mnt/hdb1/Faulty-RAIDDisk.img ?? What is the size > of /dev/hdd1? > > BTW, you don't need to edit mdadm.conf to try things out. Just > > mdadm -A /dev/md0 /dev/hdb1 /dev/hdc1 /dev/loop0 > > NeilBrown > - To unsubscribe from this list: send the line "unsubscribe linux-raid" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: NVRAM support
On Mon, Feb 13, 2006 at 11:54:44AM +, Andy Smith wrote: > On Mon, Feb 13, 2006 at 10:22:04AM +0100, Erik Mouw wrote: > > On Fri, Feb 10, 2006 at 05:02:02PM -0800, dean gaudet wrote: > > > it doesn't seem to make any sense at all to use a non-volatile external > > > memory for swap... swap has no purpose past a power outage. > > > > No, but it is a very fast swap device. Much faster than a hard drive. > > Wouldn't the same amount of money be better spent on RAM then? Sure, but when you happen to have such a device lying idle, this is a way to use it. (note that you can also use unused memory on your video adapter as a fast swap device). Erik -- +-- Erik Mouw -- www.harddisk-recovery.com -- +31 70 370 12 90 -- | Lab address: Delftechpark 26, 2628 XH, Delft, The Netherlands - To unsubscribe from this list: send the line "unsubscribe linux-raid" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: RAID 5 inaccessible - continued
On Tuesday February 14, [EMAIL PROTECTED] wrote: > Krekna is crying out loud in the empty wilderness > No one there to help me? Nope :-) > > I did the folowing: > > > > dd conv=noerror if=dev/hdd1 of=/mnt/hdb1/Faulty-RAIDDisk.img > > losetup /dev/loop0 /mnt/hdb1/Faulty-RAIDDisk.img .. > > > > But it did not work out (yet). > > > > madm -E /dev/loop0 > > mdadm: No super block found on /dev/loop0 (Expected magic a92b4efc, > > got ) ... > > > > - can I restore the superblock from the hdd1 disk (which is still alive) > > If mdadm -E /dev/hdd1 shows a valid superblock, and mdadm -E /dev/loop0 doesn't, then your 'dd' wasn't very successful. What is the size of /mnt/hdb1/Faulty-RAIDDisk.img ?? What is the size of /dev/hdd1? BTW, you don't need to edit mdadm.conf to try things out. Just mdadm -A /dev/md0 /dev/hdb1 /dev/hdc1 /dev/loop0 NeilBrown - To unsubscribe from this list: send the line "unsubscribe linux-raid" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: RAID 5 inaccessible - continued
Krekna is crying out loud in the empty wilderness
No one there to help me?
Krekna
2006/2/13, Krekna Mektek <[EMAIL PROTECTED]>:
> All right, this weekend I was able to use dd to create an imagefile
> out of the disk.
> I did the folowing:
>
> dd conv=noerror if=dev/hdd1 of=/mnt/hdb1/Faulty-RAIDDisk.img
> losetup /dev/loop0 /mnt/hdb1/Faulty-RAIDDisk.img
>
> I edited the mdadm.conf, by replacing /dev/hdd1 for /dev/loop0.
>
> But it did not work out (yet).
>
> madm -E /dev/loop0
> mdadm: No super block found on /dev/loop0 (Expected magic a92b4efc,
> got )
>
>
> How can I continue best?
>
> - mdadm -A --force /dev/md0
>
> or
>
> - can I restore the superblock from the hdd1 disk (which is still alive)
>
> or
>
> - can I configure mdadm.conf other than this:
> (/dev/hdc1 is spare, probably out of date)
>
> DEVICE /dev/hdb1 /dev/hdc1 /dev/loop0
> ARRAY /dev/md0 devices=/dev/hdb1,/dev/hdc1,/dev/loop0
>
> or
> - some other solution?
>
> Krekna
>
> 2006/2/8, Krekna Mektek <[EMAIL PROTECTED]>:
> > Hi,
> >
> > I found out that my storage drive was gone and I went to my server to
> > check out what wrong.
> > I've got 3 400GB disks wich form the array.
> >
> > I found out I had one spare and one faulty drive, and the RAID 5 array
> > was not able to recover.
> > After a reboot because of some stuff with Xen my main rootdisk (hda)
> > was also failing, and the whole machine was not able to boot anymore.
> > And there I was...
> > After I tried to commit suicide and did not succeed, I went back to my
> > server to try something out.
> > I booted with Knoppix 4.02 and edited the mdadm.conf as follows:
> >
> > DEVICE /dev/hd[bcd]1
> > ARRAY /dev/md0 devices=/dev/hdb1,/dev/hdc1,/dev/hdd1
> >
> >
> > I executed mdrun and the following messages appeared:
> >
> > Forcing event count in /dev/hdd1(2) from 81190986 upto 88231796
> > clearing FAULTY flag for device 2 in /dev/md0 for /dev/hdd1
> > /dev/md0 has been started with 2 drives (out of 3) and 1 spare.
> >
> > So I thought I was lucky enough, to get back my data, maybe a bit lost
> > concerning the event count which is missing some. Am I right?
> >
> > But, when I tried to mount it the next day, this was also not
> > happening. I ended up with one faulty, one spare and one active. After
> > stopping and starting the array sometimes the array was rebuilding
> > again. I found out that the disk that it needs to rebuilt the array
> > (hdd1 that is) is
> > getting errors and falls back to faulty again.
> >
> >
> >
> > Number Major Minor RaidDevice State
> >0 3 650 active sync
> >1 00- removed
> >2 22 652 active sync
> >
> >3 2211 spare rebuilding
> >
> >
> > and then this:
> >
> > Rebuild Status : 1% complete
> >
> > Number Major Minor RaidDevice State
> >0 3 650 active sync
> >1 00- removed
> >2 00- removed
> >
> >3 2211 spare rebuilding
> >4 22 652 faulty
> >
> > And my dmesg is full of these errors coming from the faulty hdd:
> > end_request: I/O error, dev hdd, sector 13614775
> > hdd: dma_intr: status=0x51 { DriveReady SeekComplete Error }
> > hdd: dma_intr: error=0x40 { UncorrectableError }, LBAsect=13615063,
> > high=0, low=13615063, sector=13614783
> > ide: failed opcode was: unknown
> > end_request: I/O error, dev hdd, sector 13614783
> >
> >
> > I guess this will never succeed...
> >
> > Is there away to get this data back from the individual disks perhaps?
> >
> >
> > FYI:
> >
> >
> > [EMAIL PROTECTED] cat /proc/mdstat
> > Personalities : [raid5]
> > md0 : active raid5 hdb1[0] hdc1[3] hdd1[4](F)
> > 781417472 blocks level 5, 64k chunk, algorithm 2 [3/1] [U__]
> > [>] recovery = 1.7% (6807460/390708736)
> > finish=3626.9min speed=1764K/sec
> > unused devices:
> >
> > Krekna
> >
>
-
To unsubscribe from this list: send the line "unsubscribe linux-raid" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
