Note: "permalinks" may not be as permanent as we would like,
direct links of old sources may well be a few messages off.
On Thu, Apr 20, 2006 at 03:11:42AM +0200, Ard van Breemen wrote:
> Now I hope that the other side will accept it... ;-)
Heh, sync is still going strong.
But now for something completely different:
Yeah!
Failure:
2 other systems, soft raid5, 1.1T of data,
64bit kernel, 32bit userspace, with 64 bit drbd utils.
It doesn't seem to be a good combination. The start script is just hanging on some system call, so after the
modprobe drbd
and the:
/sbin/drbdadm -d adjust all
I decided to do:
drbdadm create-md rs0
and then the:
/sbin/drbdsetup /dev/drbd0 disk /dev/md6 internal internal --on-io-error=detach
which resulted in:
drbd: initialised. Version: 8.0-pre2 (api:81/proto:80)
drbd: SVN Revision: 2139 build by ard at tessa, 2006-04-20 01:01:38
drbd: registered as block device major 147
drbd0: disk( Diskless -> Attaching )
drbd0: max_segment_size ( = BIO size ) = 0
drbd0: drbd_bm_resize called with capacity == 2318589904
drbd0: bits = 289823738 in /usr/src/kernel/tyan-s2891/modules/drbd/drbd/drbd_bitmap.c:369
drbd bytes=36227976 nbm=ffffc2000078a000 b->bm=0000000000000000
drbd0: resync bitmap: bits=289823738 words=4528496
drbd0: size = 1105 GB (1159294952 KB)
Unable to handle kernel NULL pointer dereference at 0000000000000000 RIP:
<ffffffff8047cd19>{_spin_lock_irqsave+9}
PGD 78a31067 PUD 4177a067 PMD 0
Oops: 0002 [1] SMP
CPU 0
Modules linked in: drbd ipv6 tg3 nfsd exportfs nfs lockd sunrpc
Pid: 17958, comm: drbdsetup Not tainted 2.6.17-rc1-tyan-s2891 #1
RIP: 0010:[<ffffffff8047cd19>] <ffffffff8047cd19>{_spin_lock_irqsave+9}
RSP: 0018:ffff81012fb17ac8 EFLAGS: 00010092
RAX: ffff8101000bc000 RBX: ffff810002bfe140 RCX: ffff810077be01d0
RDX: 0000000000000000 RSI: 0000000000000292 RDI: 0000000000000000
RBP: 000000000000228d R08: 8000000000000000 R09: ffff81007fdc8e40
R10: 000000002e937b84 R11: 0000000000000002 R12: ffff81007da49000
R13: ffff81007a64ba40 R14: 00000001035b4091 R15: 0000000000000001
FS: 0000000000000000(0000) GS:ffffffff80665000(0000) knlGS:00000000f7f5cb80
CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b
CR2: 0000000000000000 CR3: 000000002786a000 CR4: 00000000000006e0
Process drbdsetup (pid: 17958, threadinfo ffff81012fb16000, task ffff81017e29b100)
Stack: 0000000000000292 ffffffff8030de7d 000000000000228d 000000000000228d
000000000000228d ffffffff8812f63f 0000000000000000 ffff81007da495c0
0000000000000292 ffffffff8814107d
Call Trace: <ffffffff8030de7d>{blk_run_queue+29} <ffffffff8812f63f>{:drbd:drbd_bm_rw+127}
<ffffffff8814107d>{:drbd:drbd_al_shrink+525} <ffffffff8812e8e6>{:drbd:drbd_bm_resize+966}
<ffffffff8812e918>{:drbd:drbd_bm_resize+1016} <ffffffff8812fb1e>{:drbd:drbd_bm_write+14}
<ffffffff88131074>{:drbd:drbd_determin_dev_size+724}
<ffffffff80236088>{__mod_timer+168} <ffffffff8813142b>{:drbd:drbd_check_al_size+443}
<ffffffff88131943>{:drbd:drbd_ioctl_set_disk+1027} <ffffffff8813379f>{:drbd:drbd_ioctl+799}
<ffffffff80241979>{autoremove_wake_function+9} <ffffffff80226873>{__wake_up+67}
<ffffffff8027e2b9>{check_disk_change+41} <ffffffff8047c12f>{__mutex_unlock_slowpath+415}
<ffffffff803110f4>{blkdev_driver_ioctl+100} <ffffffff8031131c>{blkdev_ioctl+492}
<ffffffff8027e9bb>{block_ioctl+27} <ffffffff80288d3a>{do_ioctl+58}
<ffffffff80289061>{vfs_ioctl+449} <ffffffff802890dd>{sys_ioctl+77}
<ffffffff80209b1a>{system_call+126}
Code: f0 ff 0f 0f 88 59 02 00 00 48 8b 04 24 48 83 c4 08 c3 66 66
RIP <ffffffff8047cd19>{_spin_lock_irqsave+9} RSP <ffff81012fb17ac8>
CR2: 0000000000000000
The blurp about the max_segment_size is new to me. The plain /dev/sda9 version
just works. Maybe this is just the lvm problem Philip was talking about. For
that I have to compare the SVN version against the 8.0pre2 version.
Currently I am really happy about the sync rate, even in protocol C mode ...
And the most beatiful part is that I don't see any buffercache problems 8-D.
Maybe I should just sleep...
--
begin LOVE-LETTER-FOR-YOU.txt.vbs
I am a signature virus. Distribute me until the bitter
end