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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.