xfs: try to avoid blowing out the transaction reservation when bunmaping a shared...
authorDarrick J. Wong <darrick.wong@oracle.com>
Thu, 15 Jun 2017 04:25:57 +0000 (21:25 -0700)
committerDarrick J. Wong <darrick.wong@oracle.com>
Mon, 19 Jun 2017 15:59:10 +0000 (08:59 -0700)
commite1a4e37cc7b665b6804fba812aca2f4d7402c249
treec00ee8beef512215b72dd24a92f02c37012dcaba
parentd205a7d0ec47d11977882b5e910ad35f7be912b4
xfs: try to avoid blowing out the transaction reservation when bunmaping a shared extent

In a pathological scenario where we are trying to bunmapi a single
extent in which every other block is shared, it's possible that trying
to unmap the entire large extent in a single transaction can generate so
many EFIs that we overflow the transaction reservation.

Therefore, use a heuristic to guess at the number of blocks we can
safely unmap from a reflink file's data fork in an single transaction.
This should prevent problems such as the log head slamming into the tail
and ASSERTs that trigger because we've exceeded the transaction
reservation.

Note that since bunmapi can fail to unmap the entire range, we must also
teach the deferred unmap code to roll into a new transaction whenever we
get low on reservation.

Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
[hch: random edits, all bugs are my fault]
Signed-off-by: Christoph Hellwig <hch@lst.de>
fs/xfs/libxfs/xfs_bmap.c
fs/xfs/libxfs/xfs_bmap.h
fs/xfs/libxfs/xfs_refcount.c
fs/xfs/libxfs/xfs_refcount.h
fs/xfs/xfs_bmap_item.c
fs/xfs/xfs_trans.h
fs/xfs/xfs_trans_bmap.c