Note: "permalinks" may not be as permanent as we would like,
direct links of old sources may well be a few messages off.
Arnold Hendriks wrote: > I'm crudely testing whether replication works at all using 'dd': > at m1: dd if=/dev/urandom of=/dev/drbd4 bs=512 count=1 conv=fsync > oflag=sync seek=0 > at m2: less -f /dev/drbd4 > > Seeing the bytes change, I assume things are working. Now I start > iscsitarget (ietd daemon) which has been configured to export > /dev/drbd4, and without doing anything else on the machines, it seems > the syncs between m1 and m2 have stopped. Doing a new 'dd' on m1 > doesn't update the data I see on /dev/drbd4 on m2 anymore. After I > stop iscsi-target, I can see the changes I made on m2. Starting > iscsi-target makes the problem reappear. I discovered something new, after Jürgen's hint about trying to overflow the caches. Running a 8GB dd showed all drives writing in iostat, so there was definately data coming in. But still I didn't see changes However, after running 'echo 1 > /proc/sys/vm/drop_caches' to free the pagecache (which I found on http://linux-mm.org/Drop_Caches) the changes _are_ visible with 'less -f /dev/drbd4'. So with this test sequence on my system: m2: less -f /dev/drbd4 (I see data starting with <96>) m1: dd if=/dev/urandom of=/dev/drbd4 bs=512 count=1 conv=fsync oflag=sync seek=0 m2: less -f /dev/drbd4 (I still see data starting with <96>) m2: echo 1 > /proc/sys/vm/drop_caches m2 : less -f /dev/drbd4 (I see new data) So somehow it seems drbd did manage to put the data on the underlying block device (or it got there by some other route unknown to me), but is not showing it on /dev/drbd4 until I drop the caches. But it seems the problem has to be on 'm2' somewhere.. Any pointers? Arnold