Messages in this thread |  | | | Subject | nbd + raid1 + 2.4.19-pre7 | | From | Thomas Zeitlhofer <> | | Date | 22 Apr 2002 13:49:56 +0200 |
| |
The setup here:
/dev/md106: raid1 over /dev/md6 (raid1 over two ide disks) and /dev/nd6 using nbd-server and nbd-client from nbd-2.0 (sf.net/projects/nbd/)
When disconnecting the network link between nbd-server and nbd-client all processes attempting IO to /dev/nd6 are hanging in D state for exactly 15 minutes. During this time the load of the machine increases by about 2 for each IO attempt. Using the raid1 setup from above, all IO attempts to _other_ raid1 devices (e.g. /dev/md0 which is raid1 over two ide disks) are hanging in D state, too. After the 15 minutes period the load drops down and everything is working fine again - also /dev/nd6 has been marked faulty as expected. (same behavior in 2.4.18-ac3)
Any suggestions how to avoid this long time period before the machine becomes usable again?
Additionally, detaching the nbd-client (nbd-client -d) during a raid1-resync from nd6 -> md6 resulted in the following oops: ------------------------------------------------- ksymoops 2.4.5 on i686 2.4.19-pre7. Options used -V (default) -k /proc/ksyms (default) -l /proc/modules (default) -o /lib/modules/2.4.19-pre7/ (default) -m /boot/System.map-2.4.19-pre7 (specified) Apr 20 19:58:37 test1 kernel: Unable to handle kernel NULL pointer dereference at virtual address 00000018 Apr 20 19:58:37 test1 kernel: f8970164 Apr 20 19:58:37 test1 kernel: *pde = 00000000 Apr 20 19:58:37 test1 kernel: Oops: 0000 Apr 20 19:58:37 test1 kernel: CPU: 0 Apr 20 19:58:37 test1 kernel: EIP: 0010:[<f8970164>] Not tainted Using defaults from ksymoops -t elf32-i386 -a i386 Apr 20 19:58:37 test1 kernel: EFLAGS: 00010206 Apr 20 19:58:37 test1 kernel: eax: 00004100 ebx: f74cdeb4 ecx: ffffffff edx: 00000000 Apr 20 19:58:37 test1 kernel: esi: f74cdeac edi: 00001000 ebp: f770d000 esp: f74cde84 Apr 20 19:58:37 test1 kernel: ds: 0018 es: 0018 ss: 0018 Apr 20 19:58:37 test1 kernel: Process nbd-client (pid: 5695, stackpage=f74cd000) Apr 20 19:58:37 test1 kernel: Stack: f74173d8 00000a18 f74e8ac0 f8971f90 00000286 00004100 f74cdeac 00000000 Apr 20 19:58:37 test1 kernel: 00000000 c0000000 f652c000 00000000 00000000 00000000 f74cdeac 00000001 Apr 20 19:58:37 test1 kernel: 00000000 00000000 00004100 f89704a9 00000000 00000000 f770d000 00001000 Apr 20 19:58:37 test1 kernel: Call Trace: [<f8971f90>] [<f89704a9>] [<f8971f90>] [<f89704fb>] [<f8971f90>] Apr 20 19:58:37 test1 kernel: [<f89709ef>] [<f8971f90>] [<f8971f90>] [blkdev_ioctl+40/64] [sys_ioctl+359/384] [system_call+51/56] Apr 20 19:58:37 test1 kernel: Code: 8b 42 18 c7 80 88 00 00 00 30 00 00 00 8b 4c 24 18 89 6c 24
>>EIP; f8970164 <[nbd]nbd_xmit+74/190> <=====
>>eax; 00004100 Before first symbol >>ebx; f74cdeb4 <_end+3720a2f8/3853c444> >>ecx; ffffffff <END_OF_CODE+7688ed8/????> >>esi; f74cdeac <_end+3720a2f0/3853c444> >>edi; 00001000 Before first symbol >>ebp; f770d000 <_end+37449444/3853c444> >>esp; f74cde84 <_end+3720a2c8/3853c444>
Trace; f8971f90 <[nbd]nbd_dev+150/1c00> Trace; f89704a9 <[nbd]nbd_read_stat+b9/100> Trace; f8971f90 <[nbd]nbd_dev+150/1c00> Trace; f89704fb <[nbd]nbd_do_it+b/80> Trace; f8971f90 <[nbd]nbd_dev+150/1c00> Trace; f89709ef <[nbd]nbd_ioctl+31f/3f0> Trace; f8971f90 <[nbd]nbd_dev+150/1c00> Trace; f8971f90 <[nbd]nbd_dev+150/1c00>
Code; f8970164 <[nbd]nbd_xmit+74/190> 00000000 <_EIP>: Code; f8970164 <[nbd]nbd_xmit+74/190> <===== 0: 8b 42 18 mov 0x18(%edx),%eax <===== Code; f8970167 <[nbd]nbd_xmit+77/190> 3: c7 80 88 00 00 00 30 movl $0x30,0x88(%eax) Code; f897016e <[nbd]nbd_xmit+7e/190> a: 00 00 00 Code; f8970171 <[nbd]nbd_xmit+81/190> d: 8b 4c 24 18 mov 0x18(%esp,1),%ecx Code; f8970175 <[nbd]nbd_xmit+85/190> 11: 89 6c 24 00 mov %ebp,0x0(%esp,1) -------------------------------------------------
Thomas - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
|  |