From: "Darrick J. Wong" <darrick.wong@oracle.com>
To: Eric Sandeen <sandeen@sandeen.net>
Cc: linux-xfs@vger.kernel.org
Subject: Re: [PATCH 03/11] xfs_scrub: better reporting of metadata media errors
Date: Mon, 21 Oct 2019 11:10:13 -0700 [thread overview]
Message-ID: <20191021181013.GC913374@magnolia> (raw)
In-Reply-To: <a8138e48-c327-3eef-eb35-5dbe31595fcb@sandeen.net>
On Mon, Oct 21, 2019 at 11:46:23AM -0500, Eric Sandeen wrote:
> On 9/25/19 4:36 PM, Darrick J. Wong wrote:
> > From: Darrick J. Wong <darrick.wong@oracle.com>
> >
> > When we report bad metadata, we inexplicably report the physical address
> > in units of sectors, whereas for file data we report file offsets in
> > units of bytes. Fix the metadata reporting units to match the file data
> > units (i.e. bytes) and skip the printf for all other cases.
>
> kernelspace has been plagued with stuff like this - sectors vs bytes vs
> blocks, hex vs decimal, leading 0x or not ... A doc in xfs_scrub about
> how everything should be reported seems like it might be a good idea?
I'll see what I can come up with...
> > Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
> > ---
> > scrub/phase6.c | 12 +++++-------
> > 1 file changed, 5 insertions(+), 7 deletions(-)
> >
> >
> > diff --git a/scrub/phase6.c b/scrub/phase6.c
> > index a16ad114..310ab36c 100644
> > --- a/scrub/phase6.c
> > +++ b/scrub/phase6.c
> > @@ -368,7 +368,7 @@ xfs_check_rmap_error_report(
> > void *arg)
> > {
> > const char *type;
> > - char buf[32];
> > + char buf[DESCR_BUFSZ];
> > uint64_t err_physical = *(uint64_t *)arg;
> > uint64_t err_off;
> >
> > @@ -377,14 +377,12 @@ xfs_check_rmap_error_report(
> > else
> > err_off = 0;
> >
> > - snprintf(buf, 32, _("disk offset %"PRIu64),
> > - (uint64_t)BTOBB(map->fmr_physical + err_off));
> > -
>
> so did this double-report if the error was associated with a file?
This snprintf call formats the error message prefix for the case where
getfsmap tells us that a bad range intersects with some metadata...
> > + /* Report special owners */
> > if (map->fmr_flags & FMR_OF_SPECIAL_OWNER) {
> > + snprintf(buf, DESCR_BUFSZ, _("disk offset %"PRIu64),
> > + (uint64_t)map->fmr_physical + err_off);
...so we move it here to avoid wasting time on string formatting for
other badblocks cases such as the one we add in the next patch.
--D
> > type = xfs_decode_special_owner(map->fmr_owner);
> > - str_error(ctx, buf,
> > -_("%s failed read verification."),
> > - type);
> > + str_error(ctx, buf, _("media error in %s."), type);
> > }
>
>
> > /*
> >
next prev parent reply other threads:[~2019-10-21 18:10 UTC|newest]
Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-09-25 21:36 [PATCH 00/11] xfs_scrub: fix IO error reporting Darrick J. Wong
2019-09-25 21:36 ` [PATCH 01/11] xfs_scrub: separate media error reporting for attribute forks Darrick J. Wong
2019-10-21 16:18 ` Eric Sandeen
2019-10-21 17:32 ` Darrick J. Wong
2019-09-25 21:36 ` [PATCH 02/11] xfs_scrub: improve reporting of file data media errors Darrick J. Wong
2019-10-21 16:33 ` Eric Sandeen
2019-10-21 17:56 ` Darrick J. Wong
2019-09-25 21:36 ` [PATCH 03/11] xfs_scrub: better reporting of metadata " Darrick J. Wong
2019-10-21 16:46 ` Eric Sandeen
2019-10-21 18:10 ` Darrick J. Wong [this message]
2019-09-25 21:36 ` [PATCH 04/11] xfs_scrub: improve reporting of file " Darrick J. Wong
2019-10-21 16:53 ` Eric Sandeen
2019-09-25 21:36 ` [PATCH 05/11] xfs_scrub: don't report media errors on unwritten extents Darrick J. Wong
2019-10-21 16:54 ` Eric Sandeen
2019-09-25 21:36 ` [PATCH 06/11] xfs_scrub: reduce fsmap activity for media errors Darrick J. Wong
2019-10-21 17:17 ` Eric Sandeen
2019-10-21 18:14 ` Darrick J. Wong
2019-09-25 21:36 ` [PATCH 07/11] xfs_scrub: request fewer bmaps when we can Darrick J. Wong
2019-10-21 18:05 ` Eric Sandeen
2019-10-21 18:15 ` Darrick J. Wong
2019-09-25 21:36 ` [PATCH 08/11] xfs_scrub: fix media verification thread pool size calculations Darrick J. Wong
2019-10-21 19:28 ` Eric Sandeen
2019-09-25 21:37 ` [PATCH 09/11] libfrog: clean up platform_nproc Darrick J. Wong
2019-10-21 19:31 ` Eric Sandeen
2019-10-21 20:13 ` Darrick J. Wong
2019-09-25 21:37 ` [PATCH 10/11] xfs_scrub: clean out the nproc global variable Darrick J. Wong
2019-10-21 19:32 ` Eric Sandeen
2019-09-25 21:37 ` [PATCH 11/11] xfs_scrub: create a new category for unfixable errors Darrick J. Wong
2019-10-21 19:45 ` Eric Sandeen
2019-10-21 20:29 ` Darrick J. Wong
2019-10-21 20:38 ` Eric Sandeen
-- strict thread matches above, loose matches on Subject: below --
2019-09-06 3:38 [PATCH 00/11] xfs_scrub: fix IO error reporting Darrick J. Wong
2019-09-06 3:39 ` [PATCH 03/11] xfs_scrub: better reporting of metadata media errors Darrick J. Wong
2019-08-26 21:31 [PATCH 00/11] xfs_scrub: fix IO error reporting Darrick J. Wong
2019-08-26 21:31 ` [PATCH 03/11] xfs_scrub: better reporting of metadata media errors Darrick J. Wong
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=20191021181013.GC913374@magnolia \
--to=darrick.wong@oracle.com \
--cc=linux-xfs@vger.kernel.org \
--cc=sandeen@sandeen.net \
/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