• Darrick J. Wong's avatar
    xfs: try to avoid blowing out the transaction reservation when bunmaping a shared extent · e1a4e37c
    Darrick J. Wong authored
    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: default avatarDarrick J. Wong <darrick.wong@oracle.com>
    [hch: random edits, all bugs are my fault]
    Signed-off-by: default avatarChristoph Hellwig <hch@lst.de>
    e1a4e37c
xfs_bmap.c 184 KB