On Wed, Dec 18, 2013 at 04:07:27PM -0500, Josef Bacik wrote:
> qgroups need to have a consistent view of the references for a particular extent
> record. Currently they do this through sequence numbers on delayed refs, but
> this is no longer acceptable. So instead introduce lock_ref/unlock_ref. This
> will provide the qgroup code with a consistent view of the reference while it
> does its accounting calculations without interfering with the delayed ref code.
> Thanks,
>
> Signed-off-by: Josef Bacik <jbacik@xxxxxx>
> ---
> fs/btrfs/ctree.h | 11 ++++++
> fs/btrfs/delayed-ref.c | 2 +
> fs/btrfs/delayed-ref.h | 1 +
> fs/btrfs/extent-tree.c | 102 +++++++++++++++++++++++++++++++++++++++++++++++--
> 4 files changed, 113 insertions(+), 3 deletions(-)
>
> diff --git a/fs/btrfs/ctree.h b/fs/btrfs/ctree.h
> index a924274..8b3fd61 100644
> --- a/fs/btrfs/ctree.h
> +++ b/fs/btrfs/ctree.h
> @@ -1273,6 +1273,9 @@ struct btrfs_block_group_cache {
>
> /* For delayed block group creation */
> struct list_head new_bg_list;
> +
> + /* For locking reference modifications */
> + struct extent_io_tree ref_lock;
> };
>
> /* delayed seq elem */
> @@ -3319,6 +3322,14 @@ int btrfs_init_space_info(struct btrfs_fs_info *fs_info);
> int btrfs_delayed_refs_qgroup_accounting(struct btrfs_trans_handle *trans,
> struct btrfs_fs_info *fs_info);
> int __get_raid_index(u64 flags);
> +int lock_ref(struct btrfs_fs_info *fs_info, u64 root_objectid, u64 bytenr,
> + u64 num_bytes, int for_cow,
> + struct btrfs_block_group_cache **block_group,
> + struct extent_state **cached_state);
> +int unlock_ref(struct btrfs_fs_info *fs_info, u64 root_objectid, u64 bytenr,
> + u64 num_bytes, int for_cow,
> + struct btrfs_block_group_cache *block_group,
> + struct extent_state **cached_state);
Please namespace these - they are far too similar to the generic
struct lockref name and manipulation functions....
Cheers,
Dave.
--
Dave Chinner
david@xxxxxxxxxxxxx
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
