hammer errors

Sascha Wildner saw at online.de
Tue Nov 10 05:47:51 PST 2009


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 
Nov  8 03:19:41 <kern.info> yoyodyne kernel: receive error 54 from nfs 
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.


More information about the Kernel mailing list