From: "Darrick J. Wong" <djwong@kernel.org>
To: Brian Foster <bfoster@redhat.com>
Cc: linux-xfs@vger.kernel.org
Subject: Re: [PATCH] xfs: punch out data fork delalloc blocks on COW writeback failure
Date: Thu, 21 Oct 2021 11:42:53 -0700 [thread overview]
Message-ID: <20211021184253.GW24307@magnolia> (raw)
In-Reply-To: <20211021163330.1886516-1-bfoster@redhat.com>
On Thu, Oct 21, 2021 at 12:33:30PM -0400, Brian Foster wrote:
> If writeback I/O to a COW extent fails, the COW fork blocks are
> punched out and the data fork blocks left alone. It is possible for
> COW fork blocks to overlap non-shared data fork blocks (due to
> cowextsz hint prealloc), however, and writeback unconditionally maps
> to the COW fork whenever blocks exist at the corresponding offset of
> the page undergoing writeback. This means it's quite possible for a
> COW fork extent to overlap delalloc data fork blocks, writeback to
> convert and map to the COW fork blocks, writeback to fail, and
> finally for ioend completion to cancel the COW fork blocks and leave
> stale data fork delalloc blocks around in the inode. The blocks are
> effectively stale because writeback failure also discards dirty page
> state.
>
> If this occurs, it is likely to trigger assert failures, free space
> accounting corruption and failures in unrelated file operations. For
> example, a subsequent reflink attempt of the affected file to a new
> target file will trip over the stale delalloc in the source file and
> fail. Several of these issues are occasionally reproduced by
> generic/648, but are reproducible on demand with the right sequence
> of operations and timely I/O error injection.
>
> To fix this problem, update the ioend failure path to also punch out
> underlying data fork delalloc blocks on I/O error. This is analogous
> to the writeback submission failure path in xfs_discard_page() where
> we might fail to map data fork delalloc blocks and consistent with
> the successful COW writeback completion path, which is responsible
> for unmapping from the data fork and remapping in COW fork blocks.
>
> Signed-off-by: Brian Foster <bfoster@redhat.com>
> ---
>
> Note that I have an fstest to reproduce this problem reliably that I'll
> post to the list shortly.
Yay!
> Brian
>
> fs/xfs/xfs_aops.c | 15 ++++++++++++---
> 1 file changed, 12 insertions(+), 3 deletions(-)
>
> diff --git a/fs/xfs/xfs_aops.c b/fs/xfs/xfs_aops.c
> index 34fc6148032a..c8c15c3c3147 100644
> --- a/fs/xfs/xfs_aops.c
> +++ b/fs/xfs/xfs_aops.c
> @@ -82,6 +82,7 @@ xfs_end_ioend(
> struct iomap_ioend *ioend)
> {
> struct xfs_inode *ip = XFS_I(ioend->io_inode);
> + struct xfs_mount *mp = ip->i_mount;
> xfs_off_t offset = ioend->io_offset;
> size_t size = ioend->io_size;
> unsigned int nofs_flag;
> @@ -97,18 +98,26 @@ xfs_end_ioend(
> /*
> * Just clean up the in-memory structures if the fs has been shut down.
> */
> - if (xfs_is_shutdown(ip->i_mount)) {
> + if (xfs_is_shutdown(mp)) {
> error = -EIO;
> goto done;
> }
>
> /*
> - * Clean up any COW blocks on an I/O error.
> + * Clean up all COW blocks and underlying data fork delalloc blocks on
> + * I/O error. The delalloc punch is required because this ioend was
> + * mapped to blocks in the COW fork and the associated pages are no
> + * longer dirty. If we don't remove delalloc blocks here, they become
> + * stale and can corrupt free space accounting on unmount.
> */
> error = blk_status_to_errno(ioend->io_bio->bi_status);
> if (unlikely(error)) {
> - if (ioend->io_flags & IOMAP_F_SHARED)
> + if (ioend->io_flags & IOMAP_F_SHARED) {
> xfs_reflink_cancel_cow_range(ip, offset, size, true);
> + xfs_bmap_punch_delalloc_range(ip,
> + XFS_B_TO_FSBT(mp, offset),
> + XFS_B_TO_FSB(mp, size));
This looks correct to me. I'll give this a spin with your testcase and
report back.
Reviewed-by: Darrick J. Wong <djwong@kernel.org>
--D
> + }
> goto done;
> }
>
> --
> 2.31.1
>
prev parent reply other threads:[~2021-10-21 18:42 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-10-21 16:33 [PATCH] xfs: punch out data fork delalloc blocks on COW writeback failure Brian Foster
2021-10-21 18:42 ` Darrick J. Wong [this message]
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=20211021184253.GW24307@magnolia \
--to=djwong@kernel.org \
--cc=bfoster@redhat.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