hammer errors

Sascha Wildner saw at online.de
Tue Nov 10 14:48:57 PST 2009

Matthew Dillon schrieb:
: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.

    I fixed the behavior in current.  There is now a sysctl which
    controls whether it drops into the debugger or not (and it does not
    by default).  Though it doesn't panic... maybe the sysctl should be
    modified to give it the ability to panic instead of propagating an
    error code up the call chain.  The filesystem still drops into
    read-only mode if an error is encountered.
    What you want to do now is run 'hammer -f ... show | less -B' and
    search for B, as in '/^B'.  less -B uses a fixed buffer so if you
    scroll down you basically cannot scroll back up (by much), which allows
    you to pipe gigabytes and gigabytes of text through it without it
    malloc()ing itself into oblivion.  You want to try to find the problem
    area and get more context out of it, such as the object id.  And also
    to determine whether the problem area is real or not.
OK, here's some more context from the errors. Is that enough? I fear I'm 
not used enough to reading hammer show output. I will re-check the 
filesystem in an unmounted state on the weekend.

G------ ELM 24 R obj=000000011164da5c key=000000000c250000 lo=00040002 
rt=10 ot=02
                 tids 0000000111655c50:0000000000000000
B                dataoff=a00000714d120000/65536 crc=7e4f7545

G------ ELM  0 R obj=000000011164da5c key=00000000302e0000 lo=00040002 
rt=10 ot=02
                 tids 0000000111656eb0:0000000000000000
B                dataoff=a000007171380000/65536 crc=616b1cc1

obj is the same for both even though they are in different parts of the 
hammer show output.



More information about the Kernel mailing list