• D
    xfs: introduce BMAPI_ZERO for allocating zeroed extents · 3fbbbea3
    Dave Chinner 提交于
    To enable DAX to do atomic allocation of zeroed extents, we need to
    drive the block zeroing deep into the allocator. Because
    xfs_bmapi_write() can return merged extents on allocation that were
    only partially allocated (i.e. requested range spans allocated and
    hole regions, allocation into the hole was contiguous), we cannot
    zero the extent returned from xfs_bmapi_write() as that can
    overwrite existing data with zeros.
    
    Hence we have to drive the extent zeroing into the allocation code,
    prior to where we merge the extents into the BMBT and return the
    resultant map. This means we need to propagate this need down to
    the xfs_alloc_vextent() and issue the block zeroing at this point.
    
    While this functionality is being introduced for DAX, there is no
    reason why it is specific to DAX - we can per-zero blocks during the
    allocation transaction on any type of device. It's just slow (and
    usually slower than unwritten allocation and conversion) on
    traditional block devices so doesn't tend to get used. We can,
    however, hook hardware zeroing optimisations via sb_issue_zeroout()
    to this operation, so it may be useful in future and hence the
    "allocate zeroed blocks" API needs to be implementation neutral.
    Signed-off-by: NDave Chinner <dchinner@redhat.com>
    Reviewed-by: NBrian Foster <bfoster@redhat.com>
    Signed-off-by: NDave Chinner <david@fromorbit.com>
    3fbbbea3
xfs_bmap.c 171.1 KB