From: Ben Myers <bpm@sgi.com>
To: Dave Chinner <david@fromorbit.com>
Cc: xfs@oss.sgi.com
Subject: Re: [PATCH 4/3] xfs: don't assert on delalloc regions beyond EOF
Date: Tue, 8 May 2012 12:26:12 -0500 [thread overview]
Message-ID: <20120508172612.GL16881@sgi.com> (raw)
In-Reply-To: <20120429111617.GS9541@dastard>
On Sun, Apr 29, 2012 at 09:16:17PM +1000, Dave Chinner wrote:
>
> From: Dave Chinner <dchinner@redhat.com>
>
> When we are doing speculative delayed allocation beyond EOF,
> conversion of the region allocated beyond EOF is dependent on the
> largest free space extent available. If the largest free extent is
> smaller than the delalloc range, then after allocation we leave
> a delalloc extent that starts beyond EOF. This extent cannot *ever*
> be converted by flushing data, and so will remain there until either
> the EOF moves into the extent or it is truncated away.
>
> Hence if xfs_getbmap() runs on such an inode and is asked to return
> extents beyond EOF, it will assert fail on this extent even though
> there is nothing xfs_getbmap() can do to convert it to a real
> extent. Hence we should simply report these delalloc extents rather
> than assert that there should be none.
>
> Signed-off-by: Dave Chinner <dchinner@redhat.com>
> ---
> fs/xfs/xfs_bmap.c | 16 ++++++++++++++--
> 1 file changed, 14 insertions(+), 2 deletions(-)
>
> diff --git a/fs/xfs/xfs_bmap.c b/fs/xfs/xfs_bmap.c
> index 26ab256..478bce9 100644
> --- a/fs/xfs/xfs_bmap.c
> +++ b/fs/xfs/xfs_bmap.c
> @@ -5620,8 +5620,20 @@ xfs_getbmap(
> XFS_FSB_TO_BB(mp, map[i].br_blockcount);
> out[cur_ext].bmv_unused1 = 0;
> out[cur_ext].bmv_unused2 = 0;
> - ASSERT(((iflags & BMV_IF_DELALLOC) != 0) ||
> - (map[i].br_startblock != DELAYSTARTBLOCK));
> +
> + /*
> + * delayed allocation extents that start beyond EOF can
> + * occur due to speculative EOF allocation when the
> + * delalloc extent is larger than the largest freespace
> + * extent at conversion time. These extents cannot be
> + * converted by data writeback, so can exist here even
> + * if we are not supposed to be finding delalloc
> + * extents.
> + */
> + if (map[i].br_startblock == DELAYSTARTBLOCK &&
> + map[i].br_startoff <= XFS_B_TO_FSB(mp, XFS_ISIZE(ip)))
> + ASSERT((iflags & BMV_IF_DELALLOC) != 0);
> +
Looks fine. This assert will no longer kick off for delay extents after eof,
but will still catch any within the file.
Reviewed-by: Ben Myers <bpm@sgi.com>
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
next prev parent reply other threads:[~2012-05-08 17:22 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-04-27 9:45 [PATCH 0/3] xfs: failed writes and stale delalloc blocks Dave Chinner
2012-04-27 9:45 ` [PATCH 1/3] xfs: punch all delalloc blocks beyond EOF on write failure Dave Chinner
2012-04-30 13:49 ` Christoph Hellwig
2012-04-27 9:45 ` [PATCH 2/3] xfs: punch new delalloc blocks out of failed writes inside EOF Dave Chinner
2012-05-07 22:00 ` Ben Myers
2012-04-27 9:45 ` [PATCH 3/3] xfs: prevent needless mount warning causing test failures Dave Chinner
2012-05-08 16:29 ` Ben Myers
2012-05-08 22:42 ` Dave Chinner
2012-04-29 11:16 ` [PATCH 4/3] xfs: don't assert on delalloc regions beyond EOF Dave Chinner
2012-05-08 17:26 ` Ben Myers [this message]
2012-04-29 12:43 ` [PATCH 5/3] xfs: limit specualtive delalloc to maxioffset Dave Chinner
2012-05-08 18:02 ` Ben Myers
2012-04-29 12:57 ` [PATCH 6/3] xfs: make largest supported offset less shouty Dave Chinner
2012-04-29 21:58 ` Christoph Hellwig
2012-04-30 1:11 ` Dave Chinner
2012-04-30 3:03 ` Dave Chinner
2012-05-08 18:15 ` Ben Myers
2012-05-08 22:43 ` Dave Chinner
2012-05-09 19:14 ` Ben Myers
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=20120508172612.GL16881@sgi.com \
--to=bpm@sgi.com \
--cc=david@fromorbit.com \
--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.