Hi,
ever since the last time I had CRC problems on my router box, I've
developed the habit of doing a daily 'hammer -f /dev/ad4s1d show |& grep
"^B"' to see if any new errors crept up, and today I found:
yoyodyne# hammer -f /dev/ad4s1d show |& grep "^B"
B dataoff=a00000714d120000/65536 crc=7e4f7545
B dataoff=a000007171380000/65536 crc=616b1cc1
Console log for the recent days is:
Nov 7 03:15:19 <kern.crit> yoyodyne kernel: HAMMER: Warning: rebalance
caught race against propagate
Nov 7 03:15:19 <kern.crit> yoyodyne last message repeated 2 times
Nov 8 03:05:33 <kern.crit> yoyodyne kernel: bio_page_alloc: WARNING
emergency page allocation
Nov 8 03:19:41 <kern.info> yoyodyne kernel: nfs send error 32 for
server 192.168.0.10:/backup
Nov 8 03:19:41 <kern.info> yoyodyne kernel: receive error 54 from nfs
server 192.168.0.10:/backup
Nov 9 03:56:32 <kern.crit> yoyodyne kernel: Warning: vfsync_bp skipping
dirty buffer 0xc2706098
Nov 9 03:57:03 <kern.crit> yoyodyne kernel: Warning: vfsync_bp skipping
dirty buffer 0xc26eb26c
smartctl -a /dev/ad4 doesn't report any problems.
The box is running 2.4.1 (v2.4.1.8.g93de5-RELEASE, to be specific).
So my question is: What are my next steps in order to help resolve this
issue? Is there any way to get e.g. to the names of the files affected
by this problem from the data which is output by 'hammer show'?
So far the only thing I've done is to disable nightly hammer cleanup
because DragonFly, upon encountering a CRC error, will unfortunately
simply drop to the debugger without panicing, so this doesn't get caught
by DDB_UNATTENDED as far as I can tell (Matt, are there any plans to
change this unpleasant behavior?). And I won't be near that box until
next weekend.
Regards,
Sascha
--
http://yoyodyne.ath.cx
