[prev in list] [next in list] [prev in thread] [next in thread] 

List:       dragonfly-users
Subject:    Re: Hammer errors.
From:       Matthew Dillon <dillon () backplane ! com>
Date:       2021-06-30 16:31:15
Message-ID: CAOZ7CpB=QXQwK_6qZTpO+s9g_cmY5nsohRb=2ibkLB6tRuvD=w () mail ! gmail ! com
[Download RAW message or body]

It looks like several different blocks failed a CRC test in your logs.  It
would make sense to try to track down exactly where.  If you want to dive
the filesystem meta-data you can dump it with full CRC tests using:

hammer2 -vv show /dev/serno/S59ANMFNB34055E-1.s1d  > (save to a file not on
the filesystem)

And then look for 'failed)' lines in the output and track the inodes back
to see which files are affected.  Its a bit round-about and you have to get
familiar with the meta-data format, but that gives the most comprehensive
results.   The output file is typically a few gigabytes (depends how big
the filesystem is).   For example, I wound up with a single data block
error in a mail file on one of my systems, easily rectified by copying-away
the file and then deleting it.  I usually dump the output to a file and
then run less on it, then search for failed crc checks.

                  data.106     000000051676000f 00000000206a0000/16
                               vol=0 mir=0000000000149dc6
mod=0000000002572acb lfcnt=0
                               (xxhash64
32:b65e740a8f5ce753/799af250bfaf8651 failed)

A 'quick' way to try to locate problems is to use tar, something like
this.  However, tar exits when it encounters the first error so that won't
find everything, and if the problem is in a directory block that can
complicate matters.

    tar --one-file-system -cvf /dev/null /

-Matt

[Attachment #3 (text/html)]

<div dir="ltr">It looks like several different blocks failed a CRC test in your logs. \
It would make sense to try to track down exactly where.   If you want to dive the \
filesystem meta-data you can dump it with full CRC tests \
using:<div><br></div><div>hammer2 -vv show /dev/serno/S59ANMFNB34055E-1.s1d   &gt; \
(save to a file not on the filesystem)</div><div><br></div><div>And then look for \
&#39;failed)&#39; lines in the output and track the inodes back to see which files \
are affected.   Its a bit round-about and you have to get familiar with the meta-data \
format, but that gives the most comprehensive results.     The output file is \
typically a few gigabytes (depends how big the filesystem is).     For example, I \
wound up with a single data block error in a mail file on one of my systems, easily \
rectified by copying-away the file and then deleting it.   I usually dump the output \
to a file and then run less on it, then search for failed crc \
checks.</div><div><br></div><div>                           data.106       \
000000051676000f 00000000206a0000/16 <br>                                             \
vol=0 mir=0000000000149dc6 mod=0000000002572acb lfcnt=0 <br>                          \
(xxhash64 32:b65e740a8f5ce753/799af250bfaf8651 failed)  \
<br></div><div><br></div><div>A &#39;quick&#39; way to try to locate problems is to \
use tar, something like this.   However, tar exits when it encounters the first error \
so that won&#39;t find everything, and if the problem is in a directory block that \
can complicate matters.</div><div><br></div><div>      tar --one-file-system -cvf \
/dev/null /<br><div><br></div><div>-Matt<br><br></div></div></div>



[prev in list] [next in list] [prev in thread] [next in thread]