diff mbox series

[2/3] xfs: don't fail unwritten extent conversion on writeback due to edquot

Message ID 158984935767.619853.515097571114256885.stgit@magnolia (mailing list archive)
State Superseded
Headers show
Series xfs: fix stale disk exposure after crash | expand

Commit Message

Darrick J. Wong May 19, 2020, 12:49 a.m. UTC 
From: Darrick J. Wong <darrick.wong@oracle.com>

During writeback, it's possible for the quota block reservation in
xfs_iomap_write_unwritten to fail with EDQUOT because we hit the quota
limit.  This causes writeback errors for data that was already written
to disk, when it's not even guaranteed that the bmbt will expand to
exceed the quota limit.  Irritatingly, this condition is reported to
userspace as EIO by fsync, which is confusing.

We wrote the data, so allow the reservation.  That might put us slightly
above the hard limit, but it's better than losing data after a write.

Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
---
 fs/xfs/xfs_iomap.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

Comments

Christoph Hellwig May 19, 2020, 7:13 a.m. UTC | #1 
On Mon, May 18, 2020 at 05:49:17PM -0700, Darrick J. Wong wrote:
> From: Darrick J. Wong <darrick.wong@oracle.com>
> 
> During writeback, it's possible for the quota block reservation in
> xfs_iomap_write_unwritten to fail with EDQUOT because we hit the quota
> limit.  This causes writeback errors for data that was already written
> to disk, when it's not even guaranteed that the bmbt will expand to
> exceed the quota limit.  Irritatingly, this condition is reported to
> userspace as EIO by fsync, which is confusing.
> 
> We wrote the data, so allow the reservation.  That might put us slightly
> above the hard limit, but it's better than losing data after a write.
> 
> Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>

Looks good:

Reviewed-by: Christoph Hellwig <hch@lst.de>
Brian Foster May 19, 2020, 12:46 p.m. UTC | #2 
On Mon, May 18, 2020 at 05:49:17PM -0700, Darrick J. Wong wrote:
> From: Darrick J. Wong <darrick.wong@oracle.com>
> 
> During writeback, it's possible for the quota block reservation in
> xfs_iomap_write_unwritten to fail with EDQUOT because we hit the quota
> limit.  This causes writeback errors for data that was already written
> to disk, when it's not even guaranteed that the bmbt will expand to
> exceed the quota limit.  Irritatingly, this condition is reported to
> userspace as EIO by fsync, which is confusing.
> 
> We wrote the data, so allow the reservation.  That might put us slightly
> above the hard limit, but it's better than losing data after a write.
> 
> Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
> ---

Reviewed-by: Brian Foster <bfoster@redhat.com>

>  fs/xfs/xfs_iomap.c |    2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> 
> diff --git a/fs/xfs/xfs_iomap.c b/fs/xfs/xfs_iomap.c
> index bb590a267a7f..ac970b13b1f8 100644
> --- a/fs/xfs/xfs_iomap.c
> +++ b/fs/xfs/xfs_iomap.c
> @@ -563,7 +563,7 @@ xfs_iomap_write_unwritten(
>  		xfs_trans_ijoin(tp, ip, 0);
>  
>  		error = xfs_trans_reserve_quota_nblks(tp, ip, resblks, 0,
> -				XFS_QMOPT_RES_REGBLKS);
> +				XFS_QMOPT_RES_REGBLKS | XFS_QMOPT_FORCE_RES);
>  		if (error)
>  			goto error_on_bmapi_transaction;
>  
>
diff mbox series

Patch

diff --git a/fs/xfs/xfs_iomap.c b/fs/xfs/xfs_iomap.c
index bb590a267a7f..ac970b13b1f8 100644
--- a/fs/xfs/xfs_iomap.c
+++ b/fs/xfs/xfs_iomap.c
@@ -563,7 +563,7 @@  xfs_iomap_write_unwritten(
 		xfs_trans_ijoin(tp, ip, 0);
 
 		error = xfs_trans_reserve_quota_nblks(tp, ip, resblks, 0,
-				XFS_QMOPT_RES_REGBLKS);
+				XFS_QMOPT_RES_REGBLKS | XFS_QMOPT_FORCE_RES);
 		if (error)
 			goto error_on_bmapi_transaction;