[PATCH] btrfs-progs: docs: update the stability and performance status of quota

[PATCH] btrfs-progs: docs: update the stability and performance status of quota

[Qu Wenruo]

There are a lot of enhancement to btrfs quota through v5.x releases.

Now btrfs quota is more stable than it used to be.

So update the man page to relect this.

Signed-off-by: Qu Wenruo <wqu@suse.com>
---
 Documentation/btrfs-quota.asciidoc | 43 +++++++++++++++++++++++++-----
 1 file changed, 37 insertions(+), 6 deletions(-)

diff --git a/Documentation/btrfs-quota.asciidoc b/Documentation/btrfs-quota.asciidoc
index 85ebf729c2fa..1c032f11d001 100644
--- a/Documentation/btrfs-quota.asciidoc
+++ b/Documentation/btrfs-quota.asciidoc
@@ -23,16 +23,47 @@ PERFORMANCE IMPLICATIONS
 ~~~~~~~~~~~~~~~~~~~~~~~~
 
 When quotas are activated, they affect all extent processing, which takes a
-performance hit. Activation of qgroups is not recommended unless the user
-intends to actually use them.
+performance hit.
+
+Under most cases, the performance hit should be more or less acceptable for
+root fs usage.
+
+There used to be a huge performance hit for balance with quota enabled.
+That problem is solved since v5.4 kernel.
 
 STABILITY STATUS
 ~~~~~~~~~~~~~~~~
 
-The qgroup implementation has turned out to be quite difficult as it affects
-the core of the filesystem operation. Qgroup users have hit various corner cases
-over time, such as incorrect accounting or system instability. The situation is
-gradually improving and issues found and fixed.
+Btrfs quota has different stablity for different functionality:
+
+Extent accounting
+^^^^^^^^^^^^^^^^^
+
+Pretty stable, there aren't many bugs (if any) affecting the extent accounting
+through v5.x release cycles.
+
+Thus if users just want referenced/exclusive usage of each subvolume, it
+should be safe to use.
+
+Limit
+^^^^^
+
+Should be near stable since v5.9.
+
+There used to be some bugs causing early EDQUOT errors before v5.9.
+But v5.9 should solve them quite well, along with extra safe nets catching any
+reserved space leakage.
+
+Corner cases and small fixes may pop up time by time, but the core limit
+functionality should be in good shape since v5.9.
+
+Multi-level qgroups
+^^^^^^^^^^^^^^^^^^^
+
+Needs more testing. Although the core extent accounting should also work well
+for higher level qgroups, we don't have good enough test coverage yet.
+
+Thus extra testing and bug reports are welcomed.
 
 HIERARCHICAL QUOTA GROUP CONCEPTS
 ---------------------------------
-- 
2.28.0

Re: [PATCH] btrfs-progs: docs: update the stability and performance status of quota

[Neal Gompa]

On Thu, Aug 6, 2020 at 3:32 AM Qu Wenruo <wqu@suse.com> wrote:
>
> There are a lot of enhancement to btrfs quota through v5.x releases.
>
> Now btrfs quota is more stable than it used to be.
>
> So update the man page to relect this.
>
> Signed-off-by: Qu Wenruo <wqu@suse.com>
> ---
>  Documentation/btrfs-quota.asciidoc | 43 +++++++++++++++++++++++++-----
>  1 file changed, 37 insertions(+), 6 deletions(-)
>
> diff --git a/Documentation/btrfs-quota.asciidoc b/Documentation/btrfs-quota.asciidoc
> index 85ebf729c2fa..1c032f11d001 100644
> --- a/Documentation/btrfs-quota.asciidoc
> +++ b/Documentation/btrfs-quota.asciidoc
> @@ -23,16 +23,47 @@ PERFORMANCE IMPLICATIONS
>  ~~~~~~~~~~~~~~~~~~~~~~~~
>
>  When quotas are activated, they affect all extent processing, which takes a
> -performance hit. Activation of qgroups is not recommended unless the user
> -intends to actually use them.
> +performance hit.
> +
> +Under most cases, the performance hit should be more or less acceptable for
> +root fs usage.
> +
> +There used to be a huge performance hit for balance with quota enabled.
> +That problem is solved since v5.4 kernel.
>
>  STABILITY STATUS
>  ~~~~~~~~~~~~~~~~
>
> -The qgroup implementation has turned out to be quite difficult as it affects
> -the core of the filesystem operation. Qgroup users have hit various corner cases
> -over time, such as incorrect accounting or system instability. The situation is
> -gradually improving and issues found and fixed.
> +Btrfs quota has different stablity for different functionality:
> +
> +Extent accounting
> +^^^^^^^^^^^^^^^^^
> +
> +Pretty stable, there aren't many bugs (if any) affecting the extent accounting
> +through v5.x release cycles.
> +
> +Thus if users just want referenced/exclusive usage of each subvolume, it
> +should be safe to use.
> +
> +Limit
> +^^^^^
> +
> +Should be near stable since v5.9.
> +
> +There used to be some bugs causing early EDQUOT errors before v5.9.
> +But v5.9 should solve them quite well, along with extra safe nets catching any
> +reserved space leakage.
> +
> +Corner cases and small fixes may pop up time by time, but the core limit
> +functionality should be in good shape since v5.9.
> +
> +Multi-level qgroups
> +^^^^^^^^^^^^^^^^^^^
> +
> +Needs more testing. Although the core extent accounting should also work well
> +for higher level qgroups, we don't have good enough test coverage yet.
> +
> +Thus extra testing and bug reports are welcomed.
>
>  HIERARCHICAL QUOTA GROUP CONCEPTS
>  ---------------------------------
> --
> 2.28.0
>

LGTM.

Reviewed-by: Neal Gompa <ngompa13@gmail.com>

-- 
真実はいつも一つ！/ Always, there's only one truth!

Re: [PATCH] btrfs-progs: docs: update the stability and performance status of quota

[Goffredo Baroncelli]

On 8/6/20 9:29 AM, Qu Wenruo wrote:
> There are a lot of enhancement to btrfs quota through v5.x releases.
> 
> Now btrfs quota is more stable than it used to be.
> 
> So update the man page to relect this.
> 
> Signed-off-by: Qu Wenruo <wqu@suse.com>
> ---
>   Documentation/btrfs-quota.asciidoc | 43 +++++++++++++++++++++++++-----
>   1 file changed, 37 insertions(+), 6 deletions(-)
> 
> diff --git a/Documentation/btrfs-quota.asciidoc b/Documentation/btrfs-quota.asciidoc
> index 85ebf729c2fa..1c032f11d001 100644
> --- a/Documentation/btrfs-quota.asciidoc
> +++ b/Documentation/btrfs-quota.asciidoc
> @@ -23,16 +23,47 @@ PERFORMANCE IMPLICATIONS
>   ~~~~~~~~~~~~~~~~~~~~~~~~
>   
>   When quotas are activated, they affect all extent processing, which takes a
> -performance hit. Activation of qgroups is not recommended unless the user
> -intends to actually use them.
> +performance hit.
> +
> +Under most cases, the performance hit should be more or less acceptable for
> +root fs usage.
> +
> +There used to be a huge performance hit for balance with quota enabled.
> +That problem is solved since v5.4 kernel.
>   
>   STABILITY STATUS
>   ~~~~~~~~~~~~~~~~
>   
> -The qgroup implementation has turned out to be quite difficult as it affects
> -the core of the filesystem operation. Qgroup users have hit various corner cases
> -over time, such as incorrect accounting or system instability. The situation is
> -gradually improving and issues found and fixed.
> +Btrfs quota has different stablity for different functionality:
> +
> +Extent accounting
> +^^^^^^^^^^^^^^^^^
> +
> +Pretty stable, there aren't many bugs (if any) affecting the extent accounting
> +through v5.x release cycles.
> +
> +Thus if users just want referenced/exclusive usage of each subvolume, it
> +should be safe to use.
> +
> +Limit
> +^^^^^
> +
> +Should be near stable since v5.9.

Is it correct v5.9 ? We are at v5.8....

> +
> +There used to be some bugs causing early EDQUOT errors before v5.9.
> +But v5.9 should solve them quite well, along with extra safe nets catching any
> +reserved space leakage.
> +
> +Corner cases and small fixes may pop up time by time, but the core limit
> +functionality should be in good shape since v5.9.
> +
> +Multi-level qgroups
> +^^^^^^^^^^^^^^^^^^^
> +
> +Needs more testing. Although the core extent accounting should also work well
> +for higher level qgroups, we don't have good enough test coverage yet.
> +
> +Thus extra testing and bug reports are welcomed.
>   
>   HIERARCHICAL QUOTA GROUP CONCEPTS
>   ---------------------------------
> 


-- 
gpg @keyserver.linux.it: Goffredo Baroncelli <kreijackATinwind.it>
Key fingerprint BBF5 1610 0B64 DAC6 5F7D  17B2 0EDA 9B37 8B82 E0B5

Re: [PATCH] btrfs-progs: docs: update the stability and performance status of quota

[Qu Wenruo]

[-- Attachment #1.1: Type: text/plain, Size: 2933 bytes --]



On 2020/8/7 上午1:47, Goffredo Baroncelli wrote:
> On 8/6/20 9:29 AM, Qu Wenruo wrote:
>> There are a lot of enhancement to btrfs quota through v5.x releases.
>>
>> Now btrfs quota is more stable than it used to be.
>>
>> So update the man page to relect this.
>>
>> Signed-off-by: Qu Wenruo <wqu@suse.com>
>> ---
>>   Documentation/btrfs-quota.asciidoc | 43 +++++++++++++++++++++++++-----
>>   1 file changed, 37 insertions(+), 6 deletions(-)
>>
>> diff --git a/Documentation/btrfs-quota.asciidoc
>> b/Documentation/btrfs-quota.asciidoc
>> index 85ebf729c2fa..1c032f11d001 100644
>> --- a/Documentation/btrfs-quota.asciidoc
>> +++ b/Documentation/btrfs-quota.asciidoc
>> @@ -23,16 +23,47 @@ PERFORMANCE IMPLICATIONS
>>   ~~~~~~~~~~~~~~~~~~~~~~~~
>>     When quotas are activated, they affect all extent processing,
>> which takes a
>> -performance hit. Activation of qgroups is not recommended unless the
>> user
>> -intends to actually use them.
>> +performance hit.
>> +
>> +Under most cases, the performance hit should be more or less
>> acceptable for
>> +root fs usage.
>> +
>> +There used to be a huge performance hit for balance with quota enabled.
>> +That problem is solved since v5.4 kernel.
>>     STABILITY STATUS
>>   ~~~~~~~~~~~~~~~~
>>   -The qgroup implementation has turned out to be quite difficult as
>> it affects
>> -the core of the filesystem operation. Qgroup users have hit various
>> corner cases
>> -over time, such as incorrect accounting or system instability. The
>> situation is
>> -gradually improving and issues found and fixed.
>> +Btrfs quota has different stablity for different functionality:
>> +
>> +Extent accounting
>> +^^^^^^^^^^^^^^^^^
>> +
>> +Pretty stable, there aren't many bugs (if any) affecting the extent
>> accounting
>> +through v5.x release cycles.
>> +
>> +Thus if users just want referenced/exclusive usage of each subvolume, it
>> +should be safe to use.
>> +
>> +Limit
>> +^^^^^
>> +
>> +Should be near stable since v5.9.
> 
> Is it correct v5.9 ? We are at v5.8....

Yes. The fixes are in the latest torvalds' master branch, which will
become v5.9-rc1 soon.

Thanks,
Qu
> 
>> +
>> +There used to be some bugs causing early EDQUOT errors before v5.9.
>> +But v5.9 should solve them quite well, along with extra safe nets
>> catching any
>> +reserved space leakage.
>> +
>> +Corner cases and small fixes may pop up time by time, but the core limit
>> +functionality should be in good shape since v5.9.
>> +
>> +Multi-level qgroups
>> +^^^^^^^^^^^^^^^^^^^
>> +
>> +Needs more testing. Although the core extent accounting should also
>> work well
>> +for higher level qgroups, we don't have good enough test coverage yet.
>> +
>> +Thus extra testing and bug reports are welcomed.
>>     HIERARCHICAL QUOTA GROUP CONCEPTS
>>   ---------------------------------
>>
> 
> 


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]