[1/3] btrfs-progs: remove comments about delayed ref in backref.c
diff mbox

Message ID 20180424055233.6420-1-suy.fnst@cn.fujitsu.com
State New
Headers show

Commit Message

Su Yue April 24, 2018, 5:52 a.m. UTC
There is no delayed ref in btrfs-progs, so remove related comments.

Signed-off-by: Su Yue <suy.fnst@cn.fujitsu.com>
---
 backref.c | 19 +++----------------
 1 file changed, 3 insertions(+), 16 deletions(-)

Comments

Qu Wenruo April 24, 2018, 6:02 a.m. UTC | #1
On 2018年04月24日 13:52, Su Yue wrote:
> There is no delayed ref in btrfs-progs, so remove related comments.
> 

Indeed.
Delayed ref is only used to speed up extent tree modification with the
cost of code complexity.

For btrfs-progs we don't need to worry about it at all.

Thanks,
Qu

> Signed-off-by: Su Yue <suy.fnst@cn.fujitsu.com>
> ---
>  backref.c | 19 +++----------------
>  1 file changed, 3 insertions(+), 16 deletions(-)
> 
> diff --git a/backref.c b/backref.c
> index 27309e07a1e9..c144dbf060f2 100644
> --- a/backref.c
> +++ b/backref.c
> @@ -155,19 +155,6 @@ static void init_pref_state(struct pref_state *prefstate)
>   * - if you cannot add the parent or a correct key, then we will look into the
>   *   block later to set a correct key
>   *
> - * delayed refs
> - * ============
> - *        backref type | shared | indirect | shared | indirect
> - * information         |   tree |     tree |   data |     data
> - * --------------------+--------+----------+--------+----------
> - *      parent logical |    y   |     -    |    -   |     -
> - *      key to resolve |    -   |     y    |    y   |     y
> - *  tree block logical |    -   |     -    |    -   |     -
> - *  root for resolving |    y   |     y    |    y   |     y
> - *
> - * - column 1:       we've the parent -> done
> - * - column 2, 3, 4: we use the key to find the parent
> - *
>   * on disk refs (inline or keyed)
>   * ==============================
>   *        backref type | shared | indirect | shared | indirect
> @@ -735,9 +722,9 @@ static int __add_keyed_refs(struct btrfs_fs_info *fs_info,
>  }
>  
>  /*
> - * this adds all existing backrefs (inline backrefs, backrefs and delayed
> - * refs) for the given bytenr to the refs list, merges duplicates and resolves
> - * indirect refs to their parent bytenr.
> + * this adds all existing backrefs (inline backrefs, backrefs for the given
> + * bytenr to the refs list, merges duplicates and resolves indirect refs to
> + * their parent bytenr.
>   * When roots are found, they're added to the roots list
>   *
>   * FIXME some caching might speed things up
>
Su Yue April 24, 2018, 6:48 a.m. UTC | #2
On 04/24/2018 02:02 PM, Qu Wenruo wrote:
> 
> 
> On 2018年04月24日 13:52, Su Yue wrote:
>> There is no delayed ref in btrfs-progs, so remove related comments.
>>
> 
> Indeed.
> Delayed ref is only used to speed up extent tree modification with the
> cost of code complexity.
> 
Thanks for your explanation :).

> For btrfs-progs we don't need to worry about it at all.
> 
So I suggest to remove comments in progs.

Thanks,
Su

> Thanks,
> Qu
> 
>> Signed-off-by: Su Yue <suy.fnst@cn.fujitsu.com>
>> ---
>>   backref.c | 19 +++----------------
>>   1 file changed, 3 insertions(+), 16 deletions(-)
>>
>> diff --git a/backref.c b/backref.c
>> index 27309e07a1e9..c144dbf060f2 100644
>> --- a/backref.c
>> +++ b/backref.c
>> @@ -155,19 +155,6 @@ static void init_pref_state(struct pref_state *prefstate)
>>    * - if you cannot add the parent or a correct key, then we will look into the
>>    *   block later to set a correct key
>>    *
>> - * delayed refs
>> - * ============
>> - *        backref type | shared | indirect | shared | indirect
>> - * information         |   tree |     tree |   data |     data
>> - * --------------------+--------+----------+--------+----------
>> - *      parent logical |    y   |     -    |    -   |     -
>> - *      key to resolve |    -   |     y    |    y   |     y
>> - *  tree block logical |    -   |     -    |    -   |     -
>> - *  root for resolving |    y   |     y    |    y   |     y
>> - *
>> - * - column 1:       we've the parent -> done
>> - * - column 2, 3, 4: we use the key to find the parent
>> - *
>>    * on disk refs (inline or keyed)
>>    * ==============================
>>    *        backref type | shared | indirect | shared | indirect
>> @@ -735,9 +722,9 @@ static int __add_keyed_refs(struct btrfs_fs_info *fs_info,
>>   }
>>   
>>   /*
>> - * this adds all existing backrefs (inline backrefs, backrefs and delayed
>> - * refs) for the given bytenr to the refs list, merges duplicates and resolves
>> - * indirect refs to their parent bytenr.
>> + * this adds all existing backrefs (inline backrefs, backrefs for the given
>> + * bytenr to the refs list, merges duplicates and resolves indirect refs to
>> + * their parent bytenr.
>>    * When roots are found, they're added to the roots list
>>    *
>>    * FIXME some caching might speed things up
>>
> 


--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Qu Wenruo April 24, 2018, 6:51 a.m. UTC | #3
On 2018年04月24日 14:48, Su Yue wrote:
> 
> 
> On 04/24/2018 02:02 PM, Qu Wenruo wrote:
>>
>>
>> On 2018年04月24日 13:52, Su Yue wrote:
>>> There is no delayed ref in btrfs-progs, so remove related comments.
>>>
>>
>> Indeed.
>> Delayed ref is only used to speed up extent tree modification with the
>> cost of code complexity.
>>
> Thanks for your explanation :).
> 
>> For btrfs-progs we don't need to worry about it at all.
>>
> So I suggest to remove comments in progs.

Yep, I totally agree with that.

Just forgot to add:

Reviewed-by: Qu Wenruo <wqu@suse.com>

Thanks,
Qu

> 
> Thanks,
> Su
> 
>> Thanks,
>> Qu
>>
>>> Signed-off-by: Su Yue <suy.fnst@cn.fujitsu.com>
>>> ---
>>>   backref.c | 19 +++----------------
>>>   1 file changed, 3 insertions(+), 16 deletions(-)
>>>
>>> diff --git a/backref.c b/backref.c
>>> index 27309e07a1e9..c144dbf060f2 100644
>>> --- a/backref.c
>>> +++ b/backref.c
>>> @@ -155,19 +155,6 @@ static void init_pref_state(struct pref_state
>>> *prefstate)
>>>    * - if you cannot add the parent or a correct key, then we will
>>> look into the
>>>    *   block later to set a correct key
>>>    *
>>> - * delayed refs
>>> - * ============
>>> - *        backref type | shared | indirect | shared | indirect
>>> - * information         |   tree |     tree |   data |     data
>>> - * --------------------+--------+----------+--------+----------
>>> - *      parent logical |    y   |     -    |    -   |     -
>>> - *      key to resolve |    -   |     y    |    y   |     y
>>> - *  tree block logical |    -   |     -    |    -   |     -
>>> - *  root for resolving |    y   |     y    |    y   |     y
>>> - *
>>> - * - column 1:       we've the parent -> done
>>> - * - column 2, 3, 4: we use the key to find the parent
>>> - *
>>>    * on disk refs (inline or keyed)
>>>    * ==============================
>>>    *        backref type | shared | indirect | shared | indirect
>>> @@ -735,9 +722,9 @@ static int __add_keyed_refs(struct btrfs_fs_info
>>> *fs_info,
>>>   }
>>>     /*
>>> - * this adds all existing backrefs (inline backrefs, backrefs and
>>> delayed
>>> - * refs) for the given bytenr to the refs list, merges duplicates
>>> and resolves
>>> - * indirect refs to their parent bytenr.
>>> + * this adds all existing backrefs (inline backrefs, backrefs for
>>> the given
>>> + * bytenr to the refs list, merges duplicates and resolves indirect
>>> refs to
>>> + * their parent bytenr.
>>>    * When roots are found, they're added to the roots list
>>>    *
>>>    * FIXME some caching might speed things up
>>>
>>
> 
>
David Sterba May 9, 2018, 12:13 p.m. UTC | #4
On Tue, Apr 24, 2018 at 01:52:31PM +0800, Su Yue wrote:
> There is no delayed ref in btrfs-progs, so remove related comments.
> 
> Signed-off-by: Su Yue <suy.fnst@cn.fujitsu.com>

1-3 applied. Please send cover letter for patch series with more than 1
patch.
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Patch
diff mbox

diff --git a/backref.c b/backref.c
index 27309e07a1e9..c144dbf060f2 100644
--- a/backref.c
+++ b/backref.c
@@ -155,19 +155,6 @@  static void init_pref_state(struct pref_state *prefstate)
  * - if you cannot add the parent or a correct key, then we will look into the
  *   block later to set a correct key
  *
- * delayed refs
- * ============
- *        backref type | shared | indirect | shared | indirect
- * information         |   tree |     tree |   data |     data
- * --------------------+--------+----------+--------+----------
- *      parent logical |    y   |     -    |    -   |     -
- *      key to resolve |    -   |     y    |    y   |     y
- *  tree block logical |    -   |     -    |    -   |     -
- *  root for resolving |    y   |     y    |    y   |     y
- *
- * - column 1:       we've the parent -> done
- * - column 2, 3, 4: we use the key to find the parent
- *
  * on disk refs (inline or keyed)
  * ==============================
  *        backref type | shared | indirect | shared | indirect
@@ -735,9 +722,9 @@  static int __add_keyed_refs(struct btrfs_fs_info *fs_info,
 }
 
 /*
- * this adds all existing backrefs (inline backrefs, backrefs and delayed
- * refs) for the given bytenr to the refs list, merges duplicates and resolves
- * indirect refs to their parent bytenr.
+ * this adds all existing backrefs (inline backrefs, backrefs for the given
+ * bytenr to the refs list, merges duplicates and resolves indirect refs to
+ * their parent bytenr.
  * When roots are found, they're added to the roots list
  *
  * FIXME some caching might speed things up