On Mon, May 18, 2020 at 05:49:17PM -0700, Darrick J. Wong wrote: > From: Darrick J. Wong <darrick.wong@xxxxxxxxxx> > > 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@xxxxxxxxxx> > --- Reviewed-by: Brian Foster <bfoster@xxxxxxxxxx> > 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; > >
