From: Dave Chinner <david@fromorbit.com>
To: Eric Sandeen <sandeen@sandeen.net>
Cc: Eric Sandeen <sandeen@redhat.com>, xfs-oss <xfs@oss.sgi.com>
Subject: Re: [PATCH 5/6] xfs: add xfs_verifier_error()
Date: Mon, 10 Feb 2014 14:43:21 +1100 [thread overview]
Message-ID: <20140210034321.GR13647@dastard> (raw)
In-Reply-To: <52F83A8D.7030506@sandeen.net>
On Sun, Feb 09, 2014 at 08:33:49PM -0600, Eric Sandeen wrote:
> We want to distinguish between corruption, CRC errors,
> etc. In addition, the full stack trace on verifier errors
> seems less than helpful; it looks more like an oops than
> corruption.
>
> Create a new function to specifically alert the user to
> verifier errors, which can differentiate between
> EFSCORRUPTED and CRC mismatches. It doesn't dump stack
> unless the xfs error level is turned up high.
>
> Define a new error message (EFSBADCRC) to clearly identify
> CRC errors. (Defined to EILSEQ, bad byte sequence)
>
> Signed-off-by: Eric Sandeen <sandeen@redhat.com>
> ---
> fs/xfs/xfs_error.c | 22 ++++++++++++++++++++++
> fs/xfs/xfs_error.h | 3 +++
> fs/xfs/xfs_linux.h | 1 +
> 3 files changed, 26 insertions(+), 0 deletions(-)
>
> diff --git a/fs/xfs/xfs_error.c b/fs/xfs/xfs_error.c
> index 9995b80..08d76f4 100644
> --- a/fs/xfs/xfs_error.c
> +++ b/fs/xfs/xfs_error.c
> @@ -178,3 +178,25 @@ xfs_corruption_error(
> xfs_error_report(tag, level, mp, filename, linenum, ra);
> xfs_alert(mp, "Corruption detected. Unmount and run xfs_repair");
> }
> +
> +/*
> + * Warnings specifically for verifier errors. Differentiate CRC vs. invalid
> + * values, and omit the stack trace unless the error level is tuned high.
> + */
> +void
> +__xfs_verifier_error(
> + const char *func,
> + struct xfs_buf *bp)
> +{
> + struct xfs_mount *mp = bp->b_target->bt_mount;
> +
> + xfs_alert(mp,
> +"%sCorruption detected in %s, block 0x%llx. Unmount and run xfs_repair",
> + bp->b_error == EFSBADCRC ? "CRC " : "", func, bp->b_bn);
Perhaps if we do this:
xfs_alert(mp,
"Metadata %s detected at %pF, block 0x%llx. Unmount and run xfs_repair",
bp->b_error == EFSBADCRC ? "CRC error"
: "corruption", _RET_IP_, bp->b_bn);
We'll get a symbol of the form caller_name+0xoffset similar to a
stack dump. That way if we have multiple calls to a
xfs_verifier_error() inside a single function we get something that
tells us which call detected the error...
Also, the use of _RET_IP_ gets rid of the need for the wrapper
macro....
i.e. we could replace all the XFS_WANT_CORRUPTED_RETURN() calls in
__xfs_dir3_data_check() with calls to xfs_verifier_error() so we can
determine exactly what corruption check failed...
Cheers,
Dave.
--
Dave Chinner
david@fromorbit.com
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
next prev parent reply other threads:[~2014-02-10 3:43 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-02-10 2:15 [PATCH 0/6] xfs: verifier modification series Eric Sandeen
2014-02-10 2:20 ` [PATCH 1/6] xfs: limit superblock corruption errors to actual corruption Eric Sandeen
2014-02-10 2:24 ` [PATCH 2/6] xfs: skip pointless CRC updates after verifier failures Eric Sandeen
2014-02-10 2:27 ` [PATCH 3/6] xfs: add helper for verifying checksums on xfs_bufs Eric Sandeen
2014-02-10 3:31 ` Dave Chinner
2014-02-10 2:29 ` [PATCH 4/6] " Eric Sandeen
2014-02-10 3:33 ` Dave Chinner
2014-02-10 3:35 ` Eric Sandeen
2014-02-10 2:33 ` [PATCH 5/6] xfs: add xfs_verifier_error() Eric Sandeen
2014-02-10 3:43 ` Dave Chinner [this message]
2014-02-10 4:16 ` Eric Sandeen
2014-02-10 11:10 ` Dave Chinner
2014-02-10 14:52 ` Eric Sandeen
2014-02-10 2:37 ` [PATCH 6/6] xfs: modify verifiers to differentiate CRC from other errors Eric Sandeen
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20140210034321.GR13647@dastard \
--to=david@fromorbit.com \
--cc=sandeen@redhat.com \
--cc=sandeen@sandeen.net \
--cc=xfs@oss.sgi.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox