linux-btrfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Qu Wenruo <wqu@suse.de>
To: Nikolay Borisov <nborisov@suse.com>,
	Qu Wenruo <quwenruo.btrfs@gmx.com>,
	linux-btrfs@vger.kernel.org
Subject: Re: [PATCH 3/3] btrfs-progs: Create uuid tree with proper contents
Date: Wed, 2 Jan 2019 18:11:23 +0800	[thread overview]
Message-ID: <370bbd32-3b5e-cd40-4b1e-95d99f05c62e@suse.de> (raw)
In-Reply-To: <7c7a16cf-a40b-39c0-af05-aca5617dac1c@suse.com>



On 2019/1/2 下午6:07, Nikolay Borisov wrote:
> 
> 
> On 2.01.19 г. 12:00 ч., Qu Wenruo wrote:
>>
> 
> <snip>
> 
>>>> +}
>>>>  
>>>> +/*
>>>> + * Create a tree containing an root inode
>>>> + *
>>>> + * Caller must ensure at the time of calling, fs tree only contains 2 items
>>>> + * (one for INODE_ITEM and one for INODE_REF)
>>>> + */
>>>> +int create_inode_tree(struct btrfs_trans_handle *trans, u64 objectid)
>>>
>>> This function is really misnamed, since it's creating the
>>> DATA_RELOC_TREE, yet it's called create_inode_tree. Why not simply
>>> create_data_reloc_tree or are you planning on using this function more
>>> than once?
>>
>> In fact this could be used for fs, data reloc, and all subvolume trees.
>>
>> That's my primary reason not naming it create_data_reloc_tree().
>> Although currently it's only used by data reloc tree.
>>
>>>
>>>> +{
>>>> +	struct btrfs_root *fs_root = trans->fs_info->fs_root;
>>>> +
>>>> +	ASSERT(btrfs_header_level(fs_root->node) == 0 &&
>>>> +	       btrfs_header_nritems(fs_root->node) == 2);
>>>> +	return __create_tree(trans, fs_root, objectid);
>>>> +}
>>>> +
>>>> +int create_uuid_tree(struct btrfs_trans_handle *trans)
>>>> +{
>>>> +	struct btrfs_fs_info *fs_info = trans->fs_info;
>>>> +	struct btrfs_root *uuid_root = fs_info->uuid_root;
>>>> +	struct btrfs_key key;
>>>> +	int ret;
>>>> +
>>>> +	if (!uuid_root) {
>>>
>>> Isn't this always true,  so the conditional here is redundant?
>> Just a much better solution than ASSERT()/BUG_ON().
>>
>> It won't hurt and will handle wrong calling order.
> 
> What will the wrong calling order be? The only error that's possible is
> if someone calls this function twice or creates the tree outside of this
> api. This could only occur if someone is deliberately touching modifying
> the code in which case a trigger of an ASSERT should suffice to force
> them to think about what they are doing.

OK, I'll change it to ASSERT().

Thanks,
Qu

> 
>>
>> Thanks,
>> Qu
>>
> 
> <snip>
> 

  reply	other threads:[~2019-01-02 10:11 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-12-27  7:13 [PATCH for-4.20 0/3] Fix incorrectly created uuid tree Qu Wenruo
2018-12-27  7:13 ` [PATCH 1/3] btrfs-progs: uuid: Port kernel btrfs_uuid_tree_lookup() Qu Wenruo
2018-12-27  7:37   ` Su Yue
2018-12-27  7:31     ` Qu Wenruo
2018-12-27  7:13 ` [PATCH 2/3] btrfs-progs: uuid: Port btrfs_uuid_tree_add() function Qu Wenruo
2018-12-27  7:54   ` Su Yue
2018-12-27  7:13 ` [PATCH 3/3] btrfs-progs: Create uuid tree with proper contents Qu Wenruo
2018-12-27 11:28   ` Su Yue
2018-12-27 11:32     ` Qu Wenruo
2019-01-02 16:31     ` David Sterba
2019-01-02 23:46       ` Su Yue
2019-01-02  9:13   ` Nikolay Borisov
2019-01-02 10:00     ` Qu Wenruo
2019-01-02 10:07       ` Nikolay Borisov
2019-01-02 10:11         ` Qu Wenruo [this message]
2019-01-03  4:50       ` Qu Wenruo

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=370bbd32-3b5e-cd40-4b1e-95d99f05c62e@suse.de \
    --to=wqu@suse.de \
    --cc=linux-btrfs@vger.kernel.org \
    --cc=nborisov@suse.com \
    --cc=quwenruo.btrfs@gmx.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).