diff options
author | Brian Foster <bfoster@redhat.com> | 2015-08-19 09:50:12 +1000 |
---|---|---|
committer | Dave Chinner <david@fromorbit.com> | 2015-08-19 09:50:12 +1000 |
commit | 5e4b5386a2c29429add601c8cfb45bb10d80c490 (patch) | |
tree | 4818a1afca016449215b471dd557d1d3bd62357c /fs/xfs/kmem.c | |
parent | bc0195aad0daa2ad5b0d76cce22b167bc3435590 (diff) | |
download | op-kernel-dev-5e4b5386a2c29429add601c8cfb45bb10d80c490.zip op-kernel-dev-5e4b5386a2c29429add601c8cfb45bb10d80c490.tar.gz |
xfs: disentagle EFI release from the extent count
Release of the EFI either occurs based on the reference count or the
extent count. The extent count used is either the count tracked in
the EFI or EFD, depending on the particular situation. In either
case, the count is initialized to the final value and thus always
matches the current efi_next_extent value once the EFI is completely
constructed. For example, the EFI extent count is increased as the
extents are logged in xfs_bmap_finish() and the full free list is
always completely processed. Therefore, the count is guaranteed to
be complete once the EFI transaction is committed. The EFD uses the
efd_nextents counter to release the EFI. This counter is initialized
to the count of the EFI when the EFD is created. Thus the EFD, as
currently used, has no concept of partial EFI release based on
extent count.
Given that the EFI extent count is always released in whole, use of
the extent count for reference counting is unnecessary. Remove this
level of the API and release the EFI based on the core reference
count. The efi_next_extent counter remains because it is still used
to track the slot to log the next extent to free.
Signed-off-by: Brian Foster <bfoster@redhat.com>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
Diffstat (limited to 'fs/xfs/kmem.c')
0 files changed, 0 insertions, 0 deletions