big fault :-)

Hi,
I think I do something which isn't very clever ...
I needed temporarily some disk-space, so I thought:
Look at your raid, if it works you can take one disk for a short time (I use raid1).
cat /proc/mdstat looks good, so I hotremove one of two partitions. When adding the disk again with raidhotadd /dev/md1 /dev/hdb3 it starts to synchronize but it never stops to synchronize...

in messages I found:
---------------

Oct 11 17:54:24 hhbgate kernel: md: trying to hot-add hdb3 to md1 ...
Oct 11 17:54:24 hhbgate kernel: md: bind<hdb3>
Oct 11 17:54:24 hhbgate kernel: RAID1 conf printout:
Oct 11 17:54:24 hhbgate kernel:  --- wd:1 rd:2
Oct 11 17:54:24 hhbgate kernel:  disk 0, wo:0, o:1, dev:hda3
Oct 11 17:54:24 hhbgate kernel:  disk 1, wo:1, o:1, dev:hdb3
Oct 11 17:54:24 hhbgate kernel: ..<6>md: syncing RAID array md1
Oct 11 17:54:24 hhbgate kernel: md: minimum _guaranteed_ reconstruction speed: 1000 KB/sec/disc.
Oct 11 17:54:24 hhbgate kernel: md: using maximum available idle IO bandwith (but not more than 200
000 KB/sec) for reconstruction.
Oct 11 17:54:24 hhbgate kernel: md: using 128k window, over a total of 78482304 blocks.
---------------
and later, when I am around 60 % of recovering:
Oct 11 18:15:31 hhbgate kernel: hda: dma_intr: status=0x51 { DriveReady SeekComplete Error }
Oct 11 18:15:31 hhbgate kernel: hda: dma_intr: error=0x40 { UncorrectableError }, LBAsect=97562309,
 sector=97562224
Oct 11 18:15:31 hhbgate kernel: ide: failed opcode was: unknown
Oct 11 18:15:31 hhbgate kernel: end_request: I/O error, dev hda, sector 97562224
Oct 11 18:15:32 hhbgate kernel: hda: dma_intr: status=0x51 { DriveReady SeekComplete Error }
Oct 11 18:15:32 hhbgate kernel: hda: dma_intr: error=0x40 { UncorrectableError }, LBAsect=97562309,
 sector=97562232

and so on with some more sectors and later

Oct 11 18:15:44 hhbgate kernel: end_request: I/O error, dev hda, sector 97562304
Oct 11 18:15:44 hhbgate kernel: raid1: hda: unrecoverable I/O read error for block 94440448
Oct 11 18:15:44 hhbgate kernel: md: md1: sync done.
Oct 11 18:15:44 hhbgate kernel: RAID1 conf printout:
Oct 11 18:15:44 hhbgate kernel:  --- wd:1 rd:2
Oct 11 18:15:44 hhbgate kernel:  disk 0, wo:0, o:1, dev:hda3
Oct 11 18:15:44 hhbgate kernel:  disk 1, wo:1, o:1, dev:hdb3
Oct 11 18:15:44 hhbgate kernel: RAID1 conf printout:
Oct 11 18:15:44 hhbgate kernel:  --- wd:1 rd:2
Oct 11 18:15:44 hhbgate kernel:  disk 0, wo:0, o:1, dev:hda3
Oct 11 18:15:44 hhbgate kernel: RAID1 conf printout:
Oct 11 18:15:44 hhbgate kernel:  --- wd:1 rd:2
Oct 11 18:15:44 hhbgate kernel:  disk 0, wo:0, o:1, dev:hda3
Oct 11 18:15:44 hhbgate kernel:  disk 1, wo:1, o:1, dev:hdb3
Oct 11 18:15:44 hhbgate kernel: ..<6>md: syncing RAID array md1

the recovering prozess starts again and again.

Any hints what to do?

Thanks
karsten

Try to save as much data as possible to a new, known good disk - as soon as possible. You might be lucky and the data is not spread over those bad sectors...

Syncing the array will *always* hit bad sectors and thus will *always* fail.

D.

Hi and thanks for all the hints.
The problem is solved in the following way:
- checking all cables and power-connectors -> no success => hda has bad sectors
- booting with a rescue cd based on gentoo
- synching again: it runs with errors but completes
- removing hda3 from the array md1
- check reiserfs on md1 => errors and the hint to use --rebuild-tree
- backup as much as possible from md1 unsing rsync -> works, only a few files can't be read
- running reiserfsck on md1 with build-tree => success
- hoping that I get a new hard-disk in short time :-)
Thanks again
Karsten
By the way: is it possible to make a raid1 array SMALLER?
I found hints howto get it bigger and the way seems very easy, but
to shrink it? Reason: When I set up the server I have some people behind me, who mostly say: can't it be faster? - so I accepted the partions which are recommended by Suse (and which are not really suitable for my needs)

-
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

In order to do that, the file system that lives on the RAID device has to support being shrunk first, which is possible in some cases, but far from all. Typically this would involve dumping the data somewhere, shrinking the RAID, then re-creating a filesystem and moving the data back...

tw

End of included message

+--------------------------+------------------------------+
| Tim Walberg              | [email protected]      |
| 830 Carriage Dr.         | www.mindspring.com/~twalberg |
| Algonquin, IL 60102      |                              |
+--------------------------+------------------------------+
-
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

An overview of various data recovery methods:

http://dcs.nac.uci.edu/~strombrg/data-recovery.html

-
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