All of lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH] btrfs-progs: Continue checking even we found something wrong in free space cache
@ 2018-09-04 12:41 Qu Wenruo
  2018-09-11 14:48 ` David Sterba
  0 siblings, 1 reply; 4+ messages in thread
From: Qu Wenruo @ 2018-09-04 12:41 UTC (permalink / raw)
  To: linux-btrfs

No need to abort checking, especially for RO check free space cache is
meaningless, the errors in fs/extent tree is more interesting for
developers.

So continue checking even something in free space cache is wrong.

Reported-by: Etienne Champetier <champetier.etienne@gmail.com>
Signed-off-by: Qu Wenruo <wqu@suse.com>
---
 check/main.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/check/main.c b/check/main.c
index b361cd7e26a0..4f720163221e 100644
--- a/check/main.c
+++ b/check/main.c
@@ -9885,7 +9885,6 @@ int cmd_check(int argc, char **argv)
 			error("errors found in free space tree");
 		else
 			error("errors found in free space cache");
-		goto out;
 	}
 
 	/*
-- 
2.18.0

^ permalink raw reply related	[flat|nested] 4+ messages in thread

* Re: [PATCH] btrfs-progs: Continue checking even we found something wrong in free space cache
  2018-09-04 12:41 [PATCH] btrfs-progs: Continue checking even we found something wrong in free space cache Qu Wenruo
@ 2018-09-11 14:48 ` David Sterba
  2018-09-11 23:43   ` Qu Wenruo
  0 siblings, 1 reply; 4+ messages in thread
From: David Sterba @ 2018-09-11 14:48 UTC (permalink / raw)
  To: Qu Wenruo; +Cc: linux-btrfs

On Tue, Sep 04, 2018 at 08:41:28PM +0800, Qu Wenruo wrote:
> No need to abort checking, especially for RO check free space cache is
> meaningless, the errors in fs/extent tree is more interesting for
> developers.
> 
> So continue checking even something in free space cache is wrong.
> 
> Reported-by: Etienne Champetier <champetier.etienne@gmail.com>
> Signed-off-by: Qu Wenruo <wqu@suse.com>
> ---
>  check/main.c | 1 -
>  1 file changed, 1 deletion(-)
> 
> diff --git a/check/main.c b/check/main.c
> index b361cd7e26a0..4f720163221e 100644
> --- a/check/main.c
> +++ b/check/main.c
> @@ -9885,7 +9885,6 @@ int cmd_check(int argc, char **argv)
>  			error("errors found in free space tree");
>  		else
>  			error("errors found in free space cache");

Please make it a warning and update the message so it says that it will
continue despite the errors found.

I noticed that error handling in check_space_cache is a bit fishy, some
errors are stored to 'ret' but ignored at the end of the function.

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [PATCH] btrfs-progs: Continue checking even we found something wrong in free space cache
  2018-09-11 14:48 ` David Sterba
@ 2018-09-11 23:43   ` Qu Wenruo
  2018-09-14 14:32     ` David Sterba
  0 siblings, 1 reply; 4+ messages in thread
From: Qu Wenruo @ 2018-09-11 23:43 UTC (permalink / raw)
  To: dsterba, Qu Wenruo, linux-btrfs


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



On 2018/9/11 下午10:48, David Sterba wrote:
> On Tue, Sep 04, 2018 at 08:41:28PM +0800, Qu Wenruo wrote:
>> No need to abort checking, especially for RO check free space cache is
>> meaningless, the errors in fs/extent tree is more interesting for
>> developers.
>>
>> So continue checking even something in free space cache is wrong.
>>
>> Reported-by: Etienne Champetier <champetier.etienne@gmail.com>
>> Signed-off-by: Qu Wenruo <wqu@suse.com>
>> ---
>>  check/main.c | 1 -
>>  1 file changed, 1 deletion(-)
>>
>> diff --git a/check/main.c b/check/main.c
>> index b361cd7e26a0..4f720163221e 100644
>> --- a/check/main.c
>> +++ b/check/main.c
>> @@ -9885,7 +9885,6 @@ int cmd_check(int argc, char **argv)
>>  			error("errors found in free space tree");
>>  		else
>>  			error("errors found in free space cache");
> 
> Please make it a warning and update the message so it says that it will
> continue despite the errors found.

I'm fine to add warning, but isn't it the expected behavior?

In fact I'm quite surprised that when we found something wrong we just
abort checking.

It's never the case for file/extent tree check. We always report all
errors we found, not only the first error and exit.

Thanks,
Qu

> 
> I noticed that error handling in check_space_cache is a bit fishy, some
> errors are stored to 'ret' but ignored at the end of the function.
> 


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

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [PATCH] btrfs-progs: Continue checking even we found something wrong in free space cache
  2018-09-11 23:43   ` Qu Wenruo
@ 2018-09-14 14:32     ` David Sterba
  0 siblings, 0 replies; 4+ messages in thread
From: David Sterba @ 2018-09-14 14:32 UTC (permalink / raw)
  To: Qu Wenruo; +Cc: dsterba, Qu Wenruo, linux-btrfs

On Wed, Sep 12, 2018 at 07:43:27AM +0800, Qu Wenruo wrote:
> 
> 
> On 2018/9/11 下午10:48, David Sterba wrote:
> > On Tue, Sep 04, 2018 at 08:41:28PM +0800, Qu Wenruo wrote:
> >> No need to abort checking, especially for RO check free space cache is
> >> meaningless, the errors in fs/extent tree is more interesting for
> >> developers.
> >>
> >> So continue checking even something in free space cache is wrong.
> >>
> >> Reported-by: Etienne Champetier <champetier.etienne@gmail.com>
> >> Signed-off-by: Qu Wenruo <wqu@suse.com>
> >> ---
> >>  check/main.c | 1 -
> >>  1 file changed, 1 deletion(-)
> >>
> >> diff --git a/check/main.c b/check/main.c
> >> index b361cd7e26a0..4f720163221e 100644
> >> --- a/check/main.c
> >> +++ b/check/main.c
> >> @@ -9885,7 +9885,6 @@ int cmd_check(int argc, char **argv)
> >>  			error("errors found in free space tree");
> >>  		else
> >>  			error("errors found in free space cache");
> > 
> > Please make it a warning and update the message so it says that it will
> > continue despite the errors found.
> 
> I'm fine to add warning, but isn't it the expected behavior?
> 
> In fact I'm quite surprised that when we found something wrong we just
> abort checking.
> 
> It's never the case for file/extent tree check. We always report all
> errors we found, not only the first error and exit.

You're right, in context of 'check' this is the expected behaviour. So
let's keep error().

^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2018-09-14 19:46 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2018-09-04 12:41 [PATCH] btrfs-progs: Continue checking even we found something wrong in free space cache Qu Wenruo
2018-09-11 14:48 ` David Sterba
2018-09-11 23:43   ` Qu Wenruo
2018-09-14 14:32     ` David Sterba

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.