Note: "permalinks" may not be as permanent as we would like,
direct links of old sources may well be a few messages off.
>>> in context that is: >>> 14:47:43 gt3 kernel: drbd4: Online verify found 45 4k block out of sync! >>> 14:47:43 gt3 kernel: drbd4: conn( VerifyT -> Connected ) >>> 14:47:43 gt3 kernel: drbd4: Writing the whole bitmap, due to failed kmalloc >>> >>> after a disconnect and reconnect (to get the out-of-sync blocks >>> sync'd), the fsck looks a lot better. >> >> I guess when you "stomped" over it, the verify process has already been >> past that area. you should have just restarted the verify process, >> and it should have picket up on that stomping. > > no. I didn't stomp while running the verify. I stomped and then ran it. > In fact I did it a couple times, as at first I wasn't stomping on much > data, later I zeroed out a 40 meg chunk, about 40 meg into the partition. > > (hhmm, sorry, looks like it was 4 Meg into the partion, .bash_history has > this...) > > dd if=/dev/zero of=/dev/vg1/nineteen-sys seek=1000 bs=4096 count=10240 that may still have been in page cache if you ran the verify immediately after that. the verify reads directly from disk. add oflag=direct (or conv=fsync), or do some syncs, before you start the verify. > I can redo it tomorrow if you like. please do. if it still does not work as expected, first upgrade to 8.3.1. there may have been issues in 8.2.6rc2 with this stuff which I don't quite remember right now -- I'm too lazy to look it up in the git log now. our test suite says it is all working as expected. but of course, it may be wrong. so please let me know your findings. -- : Lars Ellenberg : LINBIT | Your Way to High Availability : DRBD/HA support and consulting http://www.linbit.com DRBD® and LINBIT® are registered trademarks of LINBIT, Austria.