]> git.baikalelectronics.ru Git - kernel.git/commit
xfs: remote attributes need to be considered data
authorDave Chinner <dchinner@redhat.com>
Wed, 29 Jul 2015 01:48:02 +0000 (11:48 +1000)
committerDave Chinner <david@fromorbit.com>
Wed, 29 Jul 2015 01:48:02 +0000 (11:48 +1000)
commit0d48b1deaa827e0c52c0bd2e6358796d33c47ead
tree17009e6cb40e45695db64014cc48356af53180bf
parent7d84b402f5d153bf3004706bfc7537c16dc3851e
xfs: remote attributes need to be considered data

We don't log remote attribute contents, and instead write them
synchronously before we commit the block allocation and attribute
tree update transaction. As a result we are writing to the allocated
space before the allcoation has been made permanent.

As a result, we cannot consider this allocation to be a metadata
allocation. Metadata allocation can take blocks from the free list
and so reuse them before the transaction that freed the block is
committed to disk. This behaviour is perfectly fine for journalled
metadata changes as log recovery will ensure the free operation is
replayed before the overwrite, but for remote attribute writes this
is not the case.

Hence we have to consider the remote attribute blocks to contain
data and allocate accordingly. We do this by dropping the
XFS_BMAPI_METADATA flag from the block allocation. This means the
allocation will not use blocks that are on the busy list without
first ensuring that the freeing transaction has been committed to
disk and the blocks removed from the busy list. This ensures we will
never overwrite a freed block without first ensuring that it is
really free.

cc: <stable@vger.kernel.org>
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_attr_remote.c