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
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
B dataoff=a00000714d120000/65536 crc=7e4f7545
G------ ELM 0 R obj=000000011164da5c key=00000000302e0000 lo=00040002
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