From: Brian Foster <bfoster@redhat.com>
To: Dave Chinner <david@fromorbit.com>
Cc: linux-xfs@vger.kernel.org
Subject: Re: [PATCH 2/4] xfs: skip online discard during eofblocks trims
Date: Tue, 8 May 2018 08:35:32 -0400 [thread overview]
Message-ID: <20180508123532.GC4764@bfoster.bfoster> (raw)
In-Reply-To: <20180507233819.GJ23861@dastard>
On Tue, May 08, 2018 at 09:38:19AM +1000, Dave Chinner wrote:
> On Mon, May 07, 2018 at 02:11:36PM -0400, Brian Foster wrote:
> > We've had reports of online discard operations being sent from XFS
> > on write-only workloads. These discards occur as a result of
> > eofblocks trims that can occur after a large file copy completes.
> >
> > These discards are slightly confusing for users who might be paying
> > close attention to online discards (i.e., vdo) due to performance
> > sensitivity. They also happen to be spurious because freed post-eof
> > blocks by definition have not been written to during the current
> > allocation cycle.
> >
> > Update xfs_free_eofblocks() to skip discards that are purely
> > attributed to eofblocks trims. This cuts down the number of spurious
> > discards that may occur on write-only workloads due to normal
> > preallocation activity.
> >
> > Note that discards of post-eof extents can still occur from other
> > codepaths that do not isolate handling of post-eof blocks from those
> > within eof. For example, file unlinks and truncates may still cause
> > discards for any file blocks affected by the operation.
> >
> > Signed-off-by: Brian Foster <bfoster@redhat.com>
> > ---
> > fs/xfs/xfs_attr_inactive.c | 3 ++-
> > fs/xfs/xfs_bmap_util.c | 2 +-
> > fs/xfs/xfs_inode.c | 11 ++++++++---
> > fs/xfs/xfs_inode.h | 2 +-
> > fs/xfs/xfs_iops.c | 3 ++-
> > fs/xfs/xfs_qm_syscalls.c | 2 +-
> > 6 files changed, 15 insertions(+), 8 deletions(-)
> >
> > diff --git a/fs/xfs/xfs_attr_inactive.c b/fs/xfs/xfs_attr_inactive.c
> > index 52818ea2eb50..639311e60c5d 100644
> > --- a/fs/xfs/xfs_attr_inactive.c
> > +++ b/fs/xfs/xfs_attr_inactive.c
> > @@ -434,7 +434,8 @@ xfs_attr_inactive(
> > if (error)
> > goto out_cancel;
> >
> > - error = xfs_itruncate_extents(&trans, dp, XFS_ATTR_FORK, 0);
> > + error = xfs_itruncate_extents(&trans, dp, XFS_ATTR_FORK, 0,
> > + false);
> > if (error)
> > goto out_cancel;
> > }
> > diff --git a/fs/xfs/xfs_bmap_util.c b/fs/xfs/xfs_bmap_util.c
> > index 8cd8c412f52d..7b95d8976488 100644
> > --- a/fs/xfs/xfs_bmap_util.c
> > +++ b/fs/xfs/xfs_bmap_util.c
> > @@ -872,7 +872,7 @@ xfs_free_eofblocks(
> > * may be full of holes (ie NULL files bug).
> > */
> > error = xfs_itruncate_extents(&tp, ip, XFS_DATA_FORK,
> > - XFS_ISIZE(ip));
> > + XFS_ISIZE(ip), true);
>
> xfs_itruncate_extents_nodiscard(), and then all the other
> xfs_itruncate_extents() can remain unchanged.
>
Oops, yeah.. I'll apply the same wrapper factoring approach here.
> > if (error) {
> > /*
> > * If we get an error at this point we simply don't
> > diff --git a/fs/xfs/xfs_inode.c b/fs/xfs/xfs_inode.c
> > index 2b70c8b4cee2..03b2b7099f90 100644
> > --- a/fs/xfs/xfs_inode.c
> > +++ b/fs/xfs/xfs_inode.c
> > @@ -1538,7 +1538,8 @@ xfs_itruncate_extents(
> > struct xfs_trans **tpp,
> > struct xfs_inode *ip,
> > int whichfork,
> > - xfs_fsize_t new_size)
> > + xfs_fsize_t new_size,
> > + bool skip_discard)
> > {
> > struct xfs_mount *mp = ip->i_mount;
> > struct xfs_trans *tp = *tpp;
> > @@ -1549,6 +1550,7 @@ xfs_itruncate_extents(
> > xfs_filblks_t unmap_len;
> > int error = 0;
> > int done = 0;
> > + int flags = 0;
> >
> > ASSERT(xfs_isilocked(ip, XFS_ILOCK_EXCL));
> > ASSERT(!atomic_read(&VFS_I(ip)->i_count) ||
> > @@ -1561,6 +1563,9 @@ xfs_itruncate_extents(
> >
> > trace_xfs_itruncate_extents_start(ip, new_size);
> >
> > + if (skip_discard)
> > + flags |= XFS_BMAPI_NODISCARD;
> > +
>
> flags = xfs_bmapi_aflag(whichfork);
> if (skip_discard)
> flags |= XFS_BMAPI_NODISCARD;
>
> > /*
> > * Since it is possible for space to become allocated beyond
> > * the end of the file (in a crash where the space is allocated
> > @@ -1581,7 +1586,7 @@ xfs_itruncate_extents(
> > xfs_defer_init(&dfops, &first_block);
> > error = xfs_bunmapi(tp, ip,
> > first_unmap_block, unmap_len,
> > - xfs_bmapi_aflag(whichfork),
> > + xfs_bmapi_aflag(whichfork) | flags,
>
> so this gets simpler and easier to read.
>
Indeed, thanks.
Brian
> Cheers,
>
> Dave.
> --
> Dave Chinner
> david@fromorbit.com
> --
> To unsubscribe from this list: send the line "unsubscribe linux-xfs" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
next prev parent reply other threads:[~2018-05-08 12:35 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-05-07 18:11 [PATCH 0/4] xfs: skip unnecessary discards Brian Foster
2018-05-07 18:11 ` [PATCH 1/4] xfs: add bmapi nodiscard flag Brian Foster
2018-05-07 18:11 ` [PATCH 2/4] xfs: skip online discard during eofblocks trims Brian Foster
2018-05-07 23:38 ` Dave Chinner
2018-05-08 12:35 ` Brian Foster [this message]
2018-05-07 18:11 ` [PATCH 3/4] xfs: don't discard on free of unwritten extents Brian Foster
2018-05-07 23:35 ` Dave Chinner
2018-05-08 12:36 ` Brian Foster
2018-05-07 18:11 ` [PATCH RFC 4/4] xfs: convert speculative preallocation to " Brian Foster
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=20180508123532.GC4764@bfoster.bfoster \
--to=bfoster@redhat.com \
--cc=david@fromorbit.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).