All of lore.kernel.org
 help / color / mirror / Atom feed
From: Dave Chinner <david@fromorbit.com>
To: "Darrick J. Wong" <darrick.wong@oracle.com>
Cc: xfs <linux-xfs@vger.kernel.org>, Eric Sandeen <sandeen@redhat.com>
Subject: Re: [PATCH v2] xfs: clarify units in the failed metadata io message
Date: Tue, 9 Jan 2018 09:08:17 +1100	[thread overview]
Message-ID: <20180108220817.GC16421@dastard> (raw)
In-Reply-To: <20180108213235.GW5602@magnolia>

On Mon, Jan 08, 2018 at 01:32:35PM -0800, Darrick J. Wong wrote:
> From: Darrick J. Wong <darrick.wong@oracle.com>
> 
> If a metadata IO error happens, we report the location of the failed IO
> request in units of daddrs.  However, the printk message misleads people
> into thinking that the units are fs blocks, so fix the reported units.
> 
> Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
> ---
> v2: fix more messages

A useful cleanup...

> ---
>  fs/xfs/xfs_buf.c |   13 +++++++------
>  1 file changed, 7 insertions(+), 6 deletions(-)
> 
> diff --git a/fs/xfs/xfs_buf.c b/fs/xfs/xfs_buf.c
> index 1981ef7..641b823 100644
> --- a/fs/xfs/xfs_buf.c
> +++ b/fs/xfs/xfs_buf.c
> @@ -585,8 +585,8 @@ _xfs_buf_find(
>  		 * returning a specific error on buffer lookup failures.
>  		 */
>  		xfs_alert(btp->bt_mount,
> -			  "%s: Block out of range: block 0x%llx, EOFS 0x%llx ",
> -			  __func__, cmap.bm_bn, eofs);
> +			  "%pS: daddr 0x%llx out of range, EOFS 0x%llx",
> +			  __return_address, cmap.bm_bn, eofs);

That return address won't tell us anything useful - it'll almost
always be xfs_buf_get_map(). That's why I used __func__ originally
here, and the code hasn't really changed since I did that....

>  		WARN_ON(1);
>  		return NULL;
>  	}
> @@ -1196,8 +1196,9 @@ xfs_buf_ioerror_alert(
>  	const char		*func)
>  {
>  	xfs_alert(bp->b_target->bt_mount,
> -"metadata I/O error: block 0x%llx (\"%s\") error %d numblks %d",
> -		(uint64_t)XFS_BUF_ADDR(bp), func, -bp->b_error, bp->b_length);
> +"metadata I/O error in %pS (\"%s\") at daddr 0x%llx len %d error %d",
> +			__return_address, func, (uint64_t)XFS_BUF_ADDR(bp),
> +			bp->b_length, -bp->b_error);
>  }

Same here - the return address is basically going to tell us exactly
the same information as the func parameter that is passed in.

Cheers,

Dave.

-- 
Dave Chinner
david@fromorbit.com

  reply	other threads:[~2018-01-08 22:08 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-01-08 19:40 [PATCH] xfs: clarify units in the failed metadata io message Darrick J. Wong
2018-01-08 20:19 ` Eric Sandeen
2018-01-08 20:32   ` Darrick J. Wong
2018-01-08 21:32 ` [PATCH v2] " Darrick J. Wong
2018-01-08 22:08   ` Dave Chinner [this message]
2018-01-08 22:20     ` Darrick J. Wong
2018-01-08 22:38 ` [PATCH v3] " Darrick J. Wong
2018-01-08 22:57   ` Dave Chinner

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=20180108220817.GC16421@dastard \
    --to=david@fromorbit.com \
    --cc=darrick.wong@oracle.com \
    --cc=linux-xfs@vger.kernel.org \
    --cc=sandeen@redhat.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.