From: Christoph Hellwig <hch@infradead.org>
To: "Darrick J. Wong" <djwong@kernel.org>
Cc: linux-xfs@vger.kernel.org
Subject: Re: [PATCH 2/7] xfs: refactor the predicate part of xfs_free_eofblocks
Date: Wed, 13 Jan 2021 15:57:15 +0100 [thread overview]
Message-ID: <X/8KS4it5LAkN6Xr@infradead.org> (raw)
In-Reply-To: <161040740813.1582286.3253329052236449810.stgit@magnolia>
On Mon, Jan 11, 2021 at 03:23:28PM -0800, Darrick J. Wong wrote:
> From: Darrick J. Wong <djwong@kernel.org>
>
> Refactor the part of _free_eofblocks that decides if it's really going
> to truncate post-EOF blocks into a separate helper function. The
> upcoming deferred inode inactivation patch requires us to be able to
> decide this prior to actual inactivation. No functionality changes.
Is there any specific reason why the new xfs_has_eofblocks helper is in
xfs_inode.c? That just makes following the logic a little harder.
> +
> +/*
> + * Decide if this inode have post-EOF blocks. The caller is responsible
> + * for knowing / caring about the PREALLOC/APPEND flags.
> + */
> +int
> +xfs_has_eofblocks(
> + struct xfs_inode *ip,
> + bool *has)
> +{
> + struct xfs_bmbt_irec imap;
> + struct xfs_mount *mp = ip->i_mount;
> + xfs_fileoff_t end_fsb;
> + xfs_fileoff_t last_fsb;
> + xfs_filblks_t map_len;
> + int nimaps;
> + int error;
> +
> + *has = false;
> + end_fsb = XFS_B_TO_FSB(mp, (xfs_ufsize_t)XFS_ISIZE(ip));
> + last_fsb = XFS_B_TO_FSB(mp, mp->m_super->s_maxbytes);
> + if (last_fsb <= end_fsb)
> + return 0;
Where does this strange magic come from?
> + map_len = last_fsb - end_fsb;
> +
> + nimaps = 1;
> + xfs_ilock(ip, XFS_ILOCK_SHARED);
> + error = xfs_bmapi_read(ip, end_fsb, map_len, &imap, &nimaps, 0);
> + xfs_iunlock(ip, XFS_ILOCK_SHARED);
> +
> + if (error || nimaps == 0)
> + return error;
> +
> + *has = imap.br_startblock != HOLESTARTBLOCK || ip->i_delayed_blks;
> + return 0;
I think this logic could be simplified at lot by using xfs_iext_lookup
directly. Something like:
*has = false;
xfs_ilock(ip, XFS_ILOCK_SHARED);
if (ip->i_delayed_blks) {
*has = true;
goto out_unlock;
}
if (!(ip->i_df.if_flags & XFS_IFEXTENTS)) {
error = xfs_iread_extents(NULL, ip, XFS_DATA_FORK);
if (error)
goto out_unlock;
}
if (xfs_iext_lookup_extent(ip, &ip->i_df, end_fsb, &icur, &imap))
*has = true;
out_unlock:
xfs_iunlock(ip, XFS_ILOCK_SHARED);
return error;
next prev parent reply other threads:[~2021-01-13 14:59 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-01-11 23:23 [PATCHSET v2 0/7] xfs: consolidate posteof and cowblocks cleanup Darrick J. Wong
2021-01-11 23:23 ` [PATCH 1/7] xfs: increase the default parallelism levels of pwork clients Darrick J. Wong
2021-01-13 14:49 ` Christoph Hellwig
2021-01-14 21:32 ` Darrick J. Wong
2021-01-14 22:38 ` Darrick J. Wong
2021-01-18 17:36 ` Christoph Hellwig
2021-01-18 19:57 ` Darrick J. Wong
2021-01-19 16:37 ` Christoph Hellwig
2021-01-19 19:17 ` Darrick J. Wong
2021-01-11 23:23 ` [PATCH 2/7] xfs: refactor the predicate part of xfs_free_eofblocks Darrick J. Wong
2021-01-13 14:57 ` Christoph Hellwig [this message]
2021-01-14 22:49 ` Darrick J. Wong
2021-01-18 17:38 ` Christoph Hellwig
2021-01-11 23:23 ` [PATCH 3/7] xfs: consolidate incore inode radix tree posteof/cowblocks tags Darrick J. Wong
2021-01-13 14:59 ` Christoph Hellwig
2021-01-11 23:23 ` [PATCH 4/7] xfs: consolidate the eofblocks and cowblocks workers Darrick J. Wong
2021-01-13 15:04 ` Christoph Hellwig
2021-01-13 23:53 ` Darrick J. Wong
2021-01-11 23:23 ` [PATCH 5/7] xfs: only walk the incore inode tree once per blockgc scan Darrick J. Wong
2021-01-13 15:06 ` Christoph Hellwig
2021-01-13 20:41 ` Darrick J. Wong
2021-01-11 23:23 ` [PATCH 6/7] xfs: rename block gc start and stop functions Darrick J. Wong
2021-01-13 15:07 ` Christoph Hellwig
2021-01-11 23:23 ` [PATCH 7/7] xfs: parallelize block preallocation garbage collection Darrick J. Wong
2021-01-13 15:09 ` Christoph Hellwig
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=X/8KS4it5LAkN6Xr@infradead.org \
--to=hch@infradead.org \
--cc=djwong@kernel.org \
--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