Re: [PATCH 1/2] btrfs: Rename BTRFS_ROOT_REF_COWS to BTRFS_ROOT_SHAREABLE

[David Sterba <dsterba@suse.cz>]

On Wed, May 13, 2020 at 02:16:10PM +0800, Qu Wenruo wrote:
> The name BTRFS_ROOT_REF_COWS is not helpful to show what it really
> means.
> 
> In fact, that bit can only be set to those trees:
> - Subvolume roots
> - Data reloc root
> - Reloc roots for above roots
> 
> All other trees won't get this bit set.
> So just by the result, it is obvious that, roots with this bit set can
> have tree blocks shared with other trees.
> Either shared by snapshots, or by reloc roots (an special snapshot
> created by relocation).
> 
> This patch will rename BTRFS_ROOT_REF_COWS to BTRFS_ROOT_SHAREABLE to
> make it easier to understand, and update all comment mentioning
> "reference counted" to follow the rename.

The new name sounds good to me.

> --- a/fs/btrfs/disk-io.c
> +++ b/fs/btrfs/disk-io.c
> @@ -1275,12 +1275,13 @@ static struct btrfs_root *alloc_log_tree(struct btrfs_trans_handle *trans,
>  	root->root_key.offset = BTRFS_TREE_LOG_OBJECTID;
>  
>  	/*
> -	 * DON'T set REF_COWS for log trees
> +	 * DON'T set SHAREABLE bit for log trees.
>  	 *
> -	 * log trees do not get reference counted because they go away
> -	 * before a real commit is actually done.  They do store pointers
> -	 * to file data extents, and those reference counts still get
> -	 * updated (along with back refs to the log tree).
> +	 * User has no way to create snapshot for log trees, and they go away
> +	 * before a real commit is actually done.

I think that refering to 'user' is confusing as the reference counting
or the sharing is an internal mechanics, there's no existing interface
for users to directly manipulate the log trees.

> +	 *
> +	 * They do store pointers to file data extents, and those reference
> +	 * counts still get updated (along with back refs to the log tree).
>  	 */