Skip to contentSkip to conversation

Raid5 says it's rebuilding, but it lies :)

DISCUSSION Karl Schricker 1 participant 2 messages Apr 19, 2006 – Apr 20, 2006 1 message not in the archive MD RAID

lore
Share & tools
lore

A message that is not in the archive (sent off-list or not yet received): [email protected]

#1 lore raw
Quoted 7 lines
Quoted 4 lines

mdadm -S /dev/md0
mdadm -A /dev/md0 --force /dev/sd[abd]
mdadm /dev/md0 --add /dev/sdc

All the command line tricks in the world will not change the fact that his IEEE1394 drive subsystem is presenting one or more of his drives as read only devices..

Well, the command line tricks did at least get me past the first roadblock and the array started recovering. (Thank you, Neil!)

However perhaps you are onto something, as the recovery failed halfway through with "CRC" errors. Running badblocks on the faulty disk generates lots of these errors in my log:

Apr 19 09:14:52 pingo kernel: ata2: command 0x25 timeout, stat 0xd0
host_stat 0x61
Apr 19 09:14:52 pingo kernel: ata2: status=0xd0 { Busy }
Apr 19 09:14:52 pingo kernel: SCSI error : <1 0 0 0> return code = 0x8000002
Apr 19 09:14:52 pingo kernel: sdc: Current: sense key: Aborted Command
Apr 19 09:14:52 pingo kernel:     Additional sense: Scsi parity error
Apr 19 09:14:52 pingo kernel: end_request: I/O error, dev sdc, sector 344
Apr 19 09:14:52 pingo kernel: Buffer I/O error on device sdc, logical block
43
Apr 19 09:14:52 pingo kernel: ATA: abnormal status 0xD0 on port 0x5007

Is this symptomatic of the IEEE1394 problem you mention?

I really wasn't doing anything special here. I'm using out-of-the-box packages on Mandriva 2006, not compiling kernel modules by hand. And all I did was plug in a camcorder...

Signature · 2 lines
Analog-/ISDN-Nutzer sparen mit GMX SmartSurfer bis zu 70%!
Kostenlos downloaden: http://www.gmx.net/de/go/smartsurfer
#2 lore raw
In reply to a message not in the archive
Quoted 3 lines

All the command line tricks in the world will not change the fact that his IEEE1394 drive subsystem is presenting one or more of his drives as read only devices..

Well, this turns out to have been true. The IEEE1394 package I installed included an eth1394 kernel module, which seems to have caused the conflict. Don't know why. I disabled that thing, and all of a sudden the errors stopped and the array came right back up.

Unfortunately, there must've been some data loss:

# fsck /dev/md0
fsck 1.38 (30-Jun-2005)
fsck.jfs version 1.1.7, 22-Jul-2004
processing started: 4/19/2006 21.35.4
Using default parameter: -p
The current device is:  /dev/md0
Block size in bytes:  4096
Filesystem size in blocks:  183148848
**Phase 0 - Replay Journal Log
Warning... fsck.jfs for device /dev/md0 exited with signal 11.
# mount -a
mount: wrong fs type, bad option, bad superblock on /dev/md0,
       missing codepage or other error
       In some cases useful info is found in syslog - try
       dmesg | tail  or so

Any ideas on where to take it from here?

Thanks,

Karl

Signature · 2 lines
Echte DSL-Flatrate dauerhaft für 0,- Euro*!
"Feel free" mit GMX DSL! http://www.gmx.net/de/go/dsl