Linux softraid failing, bad blocks in hdd, need help

idea

Gawd
Joined
Jan 24, 2005
Messages
615
Long story short: Brand new machine, brand new HDDs, one appears faulty.

/dev/md1 is /dev/sda6 and sdb6. sdb6 is 100%, sda6 cannot sync to it because there are i/o errors with sdb.

FACTS:
/dev/md1 resyncs to about 25% then starts over
dmesg shows i/o errors on sdb
badblocks shows results on /dev/sdb and not /dev/sda
/dev/sdb is the culprit

I need to fix the bad blocks on /dev/sdb6 so it can sync with /dev/sda6, at which point I will swap sdb with a new hard drive.

If this cannot work, or proves too difficult, another option would be to copy the files from sdb6 (I can, I already tried) to a backup directory on another array, swap the hdds, and copy it over later.

Just to weed out the noobs:
Obviously, e2fsck -cc on /dev/sdb6 won't do anything because its not ext2/3 filesystem. Its RAID autodetect.
e2fsck -cc on /dev/md1 won't work either, because RAID devices don't have "blocks"
 
have you tried to move the raid to a new computer just to make sure its not the controller on the motherboard
 
...
another option would be to copy the files from sdb6 (I can, I already tried) to a backup directory on another array, swap the hdds, and copy it over later.
I would do this right now, if you value your data.
 
Just to weed out the noobs:
Obviously, e2fsck -cc on /dev/sdb6 won't do anything because its not ext2/3 filesystem. Its RAID autodetect.

Not true for RAID-1.

RAID autodetect is a partition type, and says nothing about what is on that partition beyond it supposedly having a RAID superblock. Since you have two partitions in RAID, you are using RAID-1, which produces copies of each partition. /dev/sda6 and /dev/sdb6 (if they are healthy) contain viable filesystems that are individually mountable (regardless of whatever partition type you have selected for them). If you disabled the mirror, by deleting the RAID superblock for example, sdb6 would be just like any other partition with a filesystem. That only holds true for RAID-1, of course. It's this property that allows a Linux system to boot from a RAID-1 array without a separate non-RAIDed boot partition and initrd.

The usual filesystem utilities won't work with sdb6 because the RAID layer mirrors blocks without any understanding of the overlying filesystem structure. So any changes to sdb6 will only serve to further corrupt the RAID from the driver's point of view. That's why mapping the bad blocks on sdb6 separately from sda6 won't work while the RAID is active.

e2fsck -cc on /dev/md1 won't work either, because RAID devices don't have "blocks"


RAID devices, regardless of the RAID level, have blocks. To the kernel's VFS layer, /dev/md1 looks just like any other block device.

I need to fix the bad blocks on /dev/sdb6 so it can sync with /dev/sda6, at which point I will swap sdb with a new hard drive.

Why bother trying to sync sdb? Just unplug /dev/sdb and run with one drive in the RAID until your new drive arrives. Then plug in the new drive and do the array rebuild.
 
I need to fix the bad blocks on /dev/sdb6 so it can sync with /dev/sda6, at which point I will swap sdb with a new hard drive.
Why? If all your data is already on sda6, return your other disk and let the new one sync from the old one. There's no need to get the array consistent all the way before replacing a disk.
 
sda6 was never synced. Thats the problem. This is a new box, new hard drives, new arrays, I setup /dev/md1 for sdb6 first. Now sdb6 holds the only good copy of the array. sda6 has nothing so far. Everytime I try to sync it, the RAID fails, because sdb is causing i/o errors.

Anyway, I copied the data from sdb6 to another filesystem. I replaced the hdd with a new one. I let the arrays resync, then copied the data over. It worked.

In the future, I'd still like to know how to fix the bad blocks for a RAID partition. Just a few bad blocks shouldn't ruin an array.
 
Back
Top