On Fri, Feb 23, 2024 at 08:15:05AM +0100, Christoph Hellwig wrote: > When xfs_bmap_del_extent_delay has to split an indirect block it tries > to steal blocks from the the part that gets unmapped to increase the > indirect block reservation that now needs to cover for two extents > instead of one. > > This works perfectly fine on the data device, where the data and > indirect blocks come from the same pool. It has no chance of working > when the inode sits on the RT device. To support re-enabling delalloc > for inodes on the RT device, make this behavior conditional on not > beeing for rt extents. For an RT extent try allocate new blocks or > otherwise just give up. > > Note that split of delalloc extents should only happen on writeback > failure, as for other kinds of hole punching we first write back all > data and thus convert the delalloc reservations covering the hole to > a real allocation. > > Note that restoring a quota reservation is always a bit problematic, > but the force flag should take care of it. That is, if we actually > supported quota with the RT volume, which seems to not be the case > at the moment. ...and for anyone following along at home, this should address that problem: https://git.kernel.org/pub/scm/linux/kernel/git/djwong/xfs-linux.git/log/?h=realtime-quotas_2024-02-21 > Signed-off-by: Christoph Hellwig <hch@xxxxxx> > --- > fs/xfs/libxfs/xfs_bmap.c | 27 ++++++++++++++++++++++++++- > 1 file changed, 26 insertions(+), 1 deletion(-) > > diff --git a/fs/xfs/libxfs/xfs_bmap.c b/fs/xfs/libxfs/xfs_bmap.c > index d7fda286a4eaa0..4fa178087073b1 100644 > --- a/fs/xfs/libxfs/xfs_bmap.c > +++ b/fs/xfs/libxfs/xfs_bmap.c > @@ -4912,6 +4912,30 @@ xfs_bmap_del_extent_delay( > WARN_ON_ONCE(!got_indlen || !new_indlen); > stolen = xfs_bmap_split_indlen(da_old, &got_indlen, &new_indlen, > del->br_blockcount); > + if (isrt && stolen) { > + /* > + * Ugg, we can't just steal reservations from the data > + * blocks as the data blocks come from a different pool. > + * > + * So we have to try to increase out reservations here, "...try to increase our reservation here..." Reviewed-by: Darrick J. Wong <djwong@xxxxxxxxxx> --D > + * and if that fails we have to fail the unmap. To > + * avoid that as much as possible dip into the reserve > + * pool. > + * > + * Note that in theory the user/group/project could > + * be over the quota limit in the meantime, thus we > + * force the quota accounting even if it was over the > + * limit. > + */ > + error = xfs_dec_fdblocks(mp, stolen, true); > + if (error) { > + ip->i_delayed_blks += del->br_blockcount; > + xfs_trans_reserve_quota_nblks(NULL, ip, 0, > + del->br_blockcount, true); > + return error; > + } > + xfs_mod_delalloc(ip, 0, stolen); > + } > > got->br_startblock = nullstartblock((int)got_indlen); > > @@ -4924,7 +4948,8 @@ xfs_bmap_del_extent_delay( > xfs_iext_insert(ip, icur, &new, state); > > da_new = got_indlen + new_indlen - stolen; > - del->br_blockcount -= stolen; > + if (!isrt) > + del->br_blockcount -= stolen; > break; > } > > -- > 2.39.2 > >
