]> git.baikalelectronics.ru Git - kernel.git/commit
xfs: introduce BMAPI_ZERO for allocating zeroed extents
authorDave Chinner <dchinner@redhat.com>
Tue, 3 Nov 2015 01:27:22 +0000 (12:27 +1100)
committerDave Chinner <david@fromorbit.com>
Tue, 3 Nov 2015 01:27:22 +0000 (12:27 +1100)
commit0c1c799f4c1495f6e4000f10703919393b8e9a4b
tree2618b5476a3ac80ed4eb6dc7a3161b5d9ff5f4fc
parenta18ac8afff431925a2710a020bdfc637daf2bf7b
xfs: introduce BMAPI_ZERO for allocating zeroed extents

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: Dave Chinner <dchinner@redhat.com>
Reviewed-by: Brian Foster <bfoster@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
fs/xfs/libxfs/xfs_alloc.c
fs/xfs/libxfs/xfs_alloc.h
fs/xfs/libxfs/xfs_bmap.c
fs/xfs/libxfs/xfs_bmap.h
fs/xfs/xfs_bmap_util.c
fs/xfs/xfs_mount.h