Re: [PATCH] xfs: shut down zoned file systems on writeback errors

["Darrick J. Wong" <djwong@kernel.org>]

On Thu, Jun 11, 2026 at 09:53:05AM +0800, Yao Sang wrote:
> Zoned writeback allocates space from an open zone and advances the
> in-memory allocation state before submitting the bio.  The completion
> path only records the written blocks and updates the mapping on success.
> If the write fails, XFS cannot tell how far the device write pointer
> advanced and cannot safely roll the open zone accounting back.
> 
> This was observed while investigating xfs/643 and xfs/646 on an external
> ZNS realtime device. A writeback error after consuming space from an
> open zone left later writers waiting for open-zone or GC progress that
> could not happen. xfs/643 exposed this through the GC defragmentation
> path, while xfs/646 exposed the same failure mode through the
> truncate/EOF-zeroing space wait path.
> 
> There is no local recovery path in ioend completion that can restore a
> consistent zoned allocation state after the device has rejected the
> write. Treat writeback errors for zoned inodes as fatal and force a
> file system shutdown from the ioend completion path. The existing
> shutdown path wakes zoned allocation waiters and makes future space
> waits return -EIO instead of leaving tasks stuck waiting for progress.

File writeback errors taking down the entire filesystem?  That's pretty
drastic. :(

If writes to a zone fail, do subsequent writes to that zone also fail?

Is it possible either to requeue the failed writes to another zone?  Or
at least offline the zone and wake up the writers to convey the EIO?

(hch might have better ideas...)

--D

> Signed-off-by: Yao Sang <sangyao@kylinos.cn>
> ---
> Zoned writeback allocates space from an open zone before submitting the
> bio.  If the device later rejects the write, XFS cannot reliably recover
> the in-core open-zone allocation state from ioend completion, because it
> cannot know whether or how far the device write pointer advanced.
> 
> The issue was investigated with xfs/643 and xfs/646 on an external ZNS
> realtime device.  Both tests can expose the same failure mode once a
> writeback error happens after consuming open-zone space:
> 
> - xfs/643 exposes it through the GC defragmentation path.
> - xfs/646 exposes it through the truncate/EOF-zeroing space wait path.
> 
> Without forcing shutdown, later writers can wait for open-zone or GC
> progress that will never arrive. Forcing shutdown wakes the existing
> zoned allocation waiters and turns later waits into -EIO.
> 
> Tested with:
> - xfstests: xfs/642, xfs/643, xfs/644,
>   xfs/646, xfs/647 
> 
>  fs/xfs/xfs_aops.c | 10 ++++++++++
>  1 file changed, 10 insertions(+)
> 
> diff --git a/fs/xfs/xfs_aops.c b/fs/xfs/xfs_aops.c
> index 1a82cf625a08..4bcb47da5989 100644
> --- a/fs/xfs/xfs_aops.c
> +++ b/fs/xfs/xfs_aops.c
> @@ -139,6 +139,16 @@ xfs_end_ioend_write(
>  	 */
>  	error = blk_status_to_errno(ioend->io_bio.bi_status);
>  	if (unlikely(error)) {
> +		/*
> +		 * Zoned writes update the in-core open zone accounting before
> +		 * I/O submission.  A failed write leaves that state inconsistent,
> +		 * so shut down the filesystem instead of letting later writers
> +		 * wait forever for open zone space to become available.
> +		 */
> +		if (is_zoned) {
> +			xfs_force_shutdown(mp, SHUTDOWN_META_IO_ERROR);
> +			goto done;
> +		}
>  		if (ioend->io_flags & IOMAP_IOEND_SHARED) {
>  			ASSERT(!is_zoned);
>  			xfs_reflink_cancel_cow_range(ip, offset, size, true);
> -- 
> 2.25.1
> 
>