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). > */
