Hi,

I recently upgraded one machine from the original RedHat 5.2/kernel
2.0.36 RAID-stuff (using RAID1) to kernel 2.2.13ac3 with
raidtools-19990824-0.90.tar.gz. The partition table on both disks
looks like this:

   Device Boot    Start      End   Blocks   Id  System
/dev/sda1             1       66   530113+  83  Linux native
/dev/sda2            67     1111  8393962+   5  Extended
/dev/sda5            67      656  4739143+  fd  Unknown
/dev/sda6           657      858  1622533+  fd  Unknown
/dev/sda7           859     1060  1622533+  fd  Unknown
/dev/sda8          1061     1076   128488+  82  Linux swap
/dev/sda9          1077     1092   128488+  82  Linux swap
/dev/sda10         1093     1111   152586   fd  Unknown


The raidtab I used consists of 4 entries like this:

# /var
raiddev                 /dev/md0
        raid-level              1
        nr-raid-disks           2
        nr-spare-disks          0
        chunk-size              4

        device                  /dev/sda5
        raid-disk               0

        device                  /dev/sdb5
        raid-disk               1


The "mkraid --upgrade ..." worked quite fine. I've done this precedure
before, so I really didn't expect any problems. But during backup on
the following night, something happened:


Jan  6 00:21:14 picard kernel: attempt to access beyond end of device
Jan  6 00:21:14 picard kernel: 08:15: rw=0, want=1094795586, limit=4739143
Jan  6 00:21:14 picard kernel: dev 09:00 blksize=1024 blocknr=1094795585 
sector=-2105376126 size=1024 count=1
Jan  6 00:21:14 picard kernel: raid1: Disk failure on sdb5, disabling device.
Jan  6 00:21:14 picard kernel:        Operation continuing on 1 devices
Jan  6 00:21:14 picard kernel: raid1: md0: rescheduling block 1094795585
Jan  6 00:21:14 picard kernel: attempt to access beyond end of device
Jan  6 00:21:14 picard kernel: 08:05: rw=0, want=1094795586, limit=4739143
Jan  6 00:21:14 picard kernel: dev 09:00 blksize=1024 blocknr=1094795585 
sector=-2105376126 size=1024 count=1
Jan  6 00:21:14 picard kernel: raid1: only one disk left and IO error.
Jan  6 00:21:14 picard kernel: raid1: md0: rescheduling block 1094795585
Jan  6 00:21:14 picard kernel: attempt to access beyond end of device
Jan  6 00:21:14 picard kernel: 08:05: rw=0, want=1094795586, limit=4739143
Jan  6 00:21:14 picard kernel: dev 09:00 blksize=1024 blocknr=1094795585 
sector=-2105376126 size=1024 count=1
Jan  6 00:21:14 picard kernel: raid1: only one disk left and IO error.
Jan  6 00:21:14 picard kernel: raid1: md0: rescheduling block 1094795585
Jan  6 00:21:14 picard kernel: md: recovery thread got woken up ...
Jan  6 00:21:14 picard kernel: md0: no spare disk to reconstruct array! -- continuing 
in degraded mode
Jan  6 00:21:14 picard kernel: md: recovery thread finished ...
Jan  6 00:21:14 picard kernel: dirty sb detected, updating.
Jan  6 00:21:14 picard kernel: md: updating md0 RAID superblock on device
Jan  6 00:21:14 picard kernel: (skipping faulty sdb5 )
Jan  6 00:21:14 picard kernel: (skipping faulty sda5 )
Jan  6 00:21:14 picard kernel: .
Jan  6 00:21:14 picard kernel: raid1: md0: unrecoverable I/O read error for block 
1094795585
Jan  6 00:21:14 picard last message repeated 2 times
Jan  6 00:21:14 picard kernel: raid1: md0: redirecting sector 1094795585 to another 
mirror
Jan  6 00:21:14 picard kernel: attempt to access beyond end of device


# cat /proc/mdstat
Personalities : [linear] [raid0] [raid1] [raid5]
read_ahead 1024 sectors
md0 : active raid1 sdb5[1](F) sda5[0](F) 4739072 blocks [2/1] [U_]
md1 : active raid1 sdb6[1] sda6[0] 1622464 blocks [2/2] [UU]
md2 : active raid1 sdb7[1] sda7[0] 1622464 blocks [2/2] [UU]
md3 : active raid1 sdb10[1] sda10[0] 152512 blocks [2/2] [UU]
unused devices: <none>


I'm a bit confused and concerned about this, what have I done wrong
and how can I fix it?  The strange thing is, that everything else
seems to be fine.

Any hint welcome,
Jochen

--

# mgm ComputerSysteme und -Service GmbH
# Sophienstr. 26 / 70178 Stuttgart / Germany / Voice: +49.711.96683-5


The Internet treats censorship as a malfunction and routes around it.
       --John Perry Barlow

Reply via email to