linux-xfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Eric Sandeen <sandeen@sandeen.net>
To: "Darrick J. Wong" <darrick.wong@oracle.com>
Cc: linux-xfs@vger.kernel.org
Subject: Re: [PATCH 01/11] xfs_scrub: separate media error reporting for attribute forks
Date: Mon, 21 Oct 2019 11:18:09 -0500	[thread overview]
Message-ID: <bcb6ea07-b970-0e2e-a888-6919bf2513f7@sandeen.net> (raw)
In-Reply-To: <156944737397.300131.4607692740306012565.stgit@magnolia>

On 9/25/19 4:36 PM, Darrick J. Wong wrote:
> From: Darrick J. Wong <darrick.wong@oracle.com>
> 
> Use different functions to warn about media errors that were detected
> underlying xattr data because logical offsets for attribute fork extents
> have no meaning to users.
> 
> Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
> ---
>  scrub/phase6.c |   45 ++++++++++++++++++++++++++++++++++++++-------
>  1 file changed, 38 insertions(+), 7 deletions(-)
> 
> 
> diff --git a/scrub/phase6.c b/scrub/phase6.c
> index 4554af9a..1edd98af 100644
> --- a/scrub/phase6.c
> +++ b/scrub/phase6.c
> @@ -113,7 +113,7 @@ xfs_decode_special_owner(
>  
>  /* Report if this extent overlaps a bad region. */
>  static bool
> -xfs_report_verify_inode_bmap(
> +report_data_loss(
>  	struct scrub_ctx		*ctx,
>  	const char			*descr,
>  	int				fd,
> @@ -142,6 +142,40 @@ _("offset %llu failed read verification."), bmap->bm_offset);
>  	return true;
>  }
>  
> +/* Report if the extended attribute data overlaps a bad region. */

I'd like to see a comment above the typedef for this function
(eventually scrub_bmap_iter_fn), or above the function which uses it
(scrub_iterate_filemaps) in order to explain what the return
values mean and the implication for scanning.

Looking at this w/o a lot of context, 

"Report if the extended attribute data overlaps a bad region."

and nothing but "return true" seems ... odd.  I think what it means
is "print something if found ... and set an error for some problems,
but always continue scanning?"

> +static bool
> +report_attr_loss(
> +	struct scrub_ctx		*ctx,
> +	const char			*descr,
> +	int				fd,
> +	int				whichfork,
> +	struct fsxattr			*fsx,
> +	struct xfs_bmap			*bmap,
> +	void				*arg)
> +{
> +	struct media_verify_state	*vs = arg;
> +	struct bitmap			*bmp = vs->d_bad;
> +
> +	/* Complain about attr fork extents that don't look right. */
> +	if (bmap->bm_flags & (BMV_OF_PREALLOC | BMV_OF_DELALLOC)) {
> +		str_info(ctx, descr,
> +_("found unexpected unwritten/delalloc attr fork extent."));
> +		return true;
> +	}
> +
> +	if (fsx->fsx_xflags & FS_XFLAG_REALTIME) {
> +		str_info(ctx, descr,
> +_("found unexpected realtime attr fork extent."));
> +		return true;
> +	}

so these don't flag any error, and moveon stays true, but

> +
> +	if (bitmap_test(bmp, bmap->bm_physical, bmap->bm_length))
> +		str_error(ctx, descr,
> +_("media error in extended attribute data."));

this actually counts as an error?  OTOH report_data_loss() seems to return
false if it finds something like this, so I'm a little confused about the
difference and the behavior.  Help?

> +
> +	return true;
> +}
> +
>  /* Iterate the extent mappings of a file to report errors. */
>  static bool
>  xfs_report_verify_fd(
> @@ -155,16 +189,13 @@ xfs_report_verify_fd(
>  
>  	/* data fork */
>  	moveon = xfs_iterate_filemaps(ctx, descr, fd, XFS_DATA_FORK, &key,
> -			xfs_report_verify_inode_bmap, arg);
> +			report_data_loss, arg);
>  	if (!moveon)
>  		return false;
>  
>  	/* attr fork */
> -	moveon = xfs_iterate_filemaps(ctx, descr, fd, XFS_ATTR_FORK, &key,
> -			xfs_report_verify_inode_bmap, arg);
> -	if (!moveon)
> -		return false;
> -	return true;
> +	return xfs_iterate_filemaps(ctx, descr, fd, XFS_ATTR_FORK, &key,
> +			report_attr_loss, arg);
>  }
>  
>  /* Report read verify errors in unlinked (but still open) files. */
> 

  reply	other threads:[~2019-10-21 16:18 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 [this message]
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
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 01/11] xfs_scrub: separate media error reporting for attribute forks 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 01/11] xfs_scrub: separate media error reporting for attribute forks 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=bcb6ea07-b970-0e2e-a888-6919bf2513f7@sandeen.net \
    --to=sandeen@sandeen.net \
    --cc=darrick.wong@oracle.com \
    --cc=linux-xfs@vger.kernel.org \
    /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;
as well as URLs for NNTP newsgroup(s).