All of lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH] btrfs: scrub: respect the read-only flag during repair
@ 2023-06-06  2:05 Qu Wenruo
  2023-06-08 11:56 ` David Sterba
  0 siblings, 1 reply; 4+ messages in thread
From: Qu Wenruo @ 2023-06-06  2:05 UTC (permalink / raw)
  To: linux-btrfs

[BUG]
With recent scrub rework, the scrub operation no longer respects the
read-only flag passed by "-r" option of "btrfs scrub start" command.

 # mkfs.btrfs -f -d raid1 $dev1 $dev2
 # mount $dev1 $mnt
 # xfs_io -f -d -c "pwrite -b 128K -S 0xaa 0 128k" $mnt/file
 # sync
 # xfs_io -c "pwrite -S 0xff $phy1 64k" $dev1
 # xfs_io -c "pwrite -S 0xff $((phy2 + 65536)) 64k" $dev2
 # mount $dev1 $mnt -o ro
 # btrfs scrub start -BrRd $mnt
 Scrub device $dev1 (id 1) done
 Scrub started:    Tue Jun  6 09:59:14 2023
 Status:           finished
 Duration:         0:00:00
	[...]
 	corrected_errors: 16 <<< Still has corrupted sectors
 	last_physical: 1372585984

 Scrub device $dev2 (id 2) done
 Scrub started:    Tue Jun  6 09:59:14 2023
 Status:           finished
 Duration:         0:00:00
	[...]
 	corrected_errors: 16 <<< Still has corrupted sectors
 	last_physical: 1351614464

 # btrfs scrub start -BrRd $mnt
 Scrub device $dev1 (id 1) done
 Scrub started:    Tue Jun  6 10:00:17 2023
 Status:           finished
 Duration:         0:00:00
	[...]
 	corrected_errors: 0 <<< No more errors
 	last_physical: 1372585984

 Scrub device $dev2 (id 2) done
	[...]
 	corrected_errors: 0 <<< No more errors
 	last_physical: 1372585984

[CAUSE]
In the newly reworked scrub code, repair is always submitted no matter
if we're doing a read-only scrub.

[FIX]
Fix it by skipping the write submission if the scrub is a read-only one.

Unfortunately for the report part, even for a read-only scrub we will
still report it as corrected errors, as we know it's repairable, even we
won't really submit the write.

Fixes: e02ee89baa66 ("btrfs: scrub: switch scrub_simple_mirror() to scrub_stripe infrastructure")
Signed-off-by: Qu Wenruo <wqu@suse.com>
---
 fs/btrfs/scrub.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/fs/btrfs/scrub.c b/fs/btrfs/scrub.c
index 28caad17ccc7..375c1f8fef4d 100644
--- a/fs/btrfs/scrub.c
+++ b/fs/btrfs/scrub.c
@@ -1695,7 +1695,7 @@ static int flush_scrub_stripes(struct scrub_ctx *sctx)
 				break;
 			}
 		}
-	} else {
+	} else if (!sctx->readonly) {
 		for (int i = 0; i < nr_stripes; i++) {
 			unsigned long repaired;
 
-- 
2.40.1


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

* Re: [PATCH] btrfs: scrub: respect the read-only flag during repair
  2023-06-06  2:05 [PATCH] btrfs: scrub: respect the read-only flag during repair Qu Wenruo
@ 2023-06-08 11:56 ` David Sterba
  2023-06-08 12:08   ` Qu Wenruo
  0 siblings, 1 reply; 4+ messages in thread
From: David Sterba @ 2023-06-08 11:56 UTC (permalink / raw)
  To: Qu Wenruo; +Cc: linux-btrfs

On Tue, Jun 06, 2023 at 10:05:04AM +0800, Qu Wenruo wrote:
> [BUG]
> With recent scrub rework, the scrub operation no longer respects the
> read-only flag passed by "-r" option of "btrfs scrub start" command.
> 
>  # mkfs.btrfs -f -d raid1 $dev1 $dev2
>  # mount $dev1 $mnt
>  # xfs_io -f -d -c "pwrite -b 128K -S 0xaa 0 128k" $mnt/file
>  # sync
>  # xfs_io -c "pwrite -S 0xff $phy1 64k" $dev1
>  # xfs_io -c "pwrite -S 0xff $((phy2 + 65536)) 64k" $dev2
>  # mount $dev1 $mnt -o ro
>  # btrfs scrub start -BrRd $mnt
>  Scrub device $dev1 (id 1) done
>  Scrub started:    Tue Jun  6 09:59:14 2023
>  Status:           finished
>  Duration:         0:00:00
> 	[...]
>  	corrected_errors: 16 <<< Still has corrupted sectors
>  	last_physical: 1372585984
> 
>  Scrub device $dev2 (id 2) done
>  Scrub started:    Tue Jun  6 09:59:14 2023
>  Status:           finished
>  Duration:         0:00:00
> 	[...]
>  	corrected_errors: 16 <<< Still has corrupted sectors
>  	last_physical: 1351614464
> 
>  # btrfs scrub start -BrRd $mnt
>  Scrub device $dev1 (id 1) done
>  Scrub started:    Tue Jun  6 10:00:17 2023
>  Status:           finished
>  Duration:         0:00:00
> 	[...]
>  	corrected_errors: 0 <<< No more errors
>  	last_physical: 1372585984
> 
>  Scrub device $dev2 (id 2) done
> 	[...]
>  	corrected_errors: 0 <<< No more errors
>  	last_physical: 1372585984
> 
> [CAUSE]
> In the newly reworked scrub code, repair is always submitted no matter
> if we're doing a read-only scrub.
> 
> [FIX]
> Fix it by skipping the write submission if the scrub is a read-only one.
> 
> Unfortunately for the report part, even for a read-only scrub we will
> still report it as corrected errors, as we know it's repairable, even we
> won't really submit the write.

We can maybe present the results in scrub status in an different way
when it's started as read-only, e.g. not to say "repaired" but
"repairable (read-only)".

> Fixes: e02ee89baa66 ("btrfs: scrub: switch scrub_simple_mirror() to scrub_stripe infrastructure")
> Signed-off-by: Qu Wenruo <wqu@suse.com>

Added to misc-next, thanks.

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

* Re: [PATCH] btrfs: scrub: respect the read-only flag during repair
  2023-06-08 12:08   ` Qu Wenruo
@ 2023-06-08 12:07     ` David Sterba
  0 siblings, 0 replies; 4+ messages in thread
From: David Sterba @ 2023-06-08 12:07 UTC (permalink / raw)
  To: Qu Wenruo; +Cc: dsterba, linux-btrfs

On Thu, Jun 08, 2023 at 08:08:25PM +0800, Qu Wenruo wrote:
> 
> 
> On 2023/6/8 19:56, David Sterba wrote:
> > On Tue, Jun 06, 2023 at 10:05:04AM +0800, Qu Wenruo wrote:
> >> [BUG]
> >> With recent scrub rework, the scrub operation no longer respects the
> >> read-only flag passed by "-r" option of "btrfs scrub start" command.
> >>
> >>   # mkfs.btrfs -f -d raid1 $dev1 $dev2
> >>   # mount $dev1 $mnt
> >>   # xfs_io -f -d -c "pwrite -b 128K -S 0xaa 0 128k" $mnt/file
> >>   # sync
> >>   # xfs_io -c "pwrite -S 0xff $phy1 64k" $dev1
> >>   # xfs_io -c "pwrite -S 0xff $((phy2 + 65536)) 64k" $dev2
> >>   # mount $dev1 $mnt -o ro
> >>   # btrfs scrub start -BrRd $mnt
> >>   Scrub device $dev1 (id 1) done
> >>   Scrub started:    Tue Jun  6 09:59:14 2023
> >>   Status:           finished
> >>   Duration:         0:00:00
> >> 	[...]
> >>   	corrected_errors: 16 <<< Still has corrupted sectors
> >>   	last_physical: 1372585984
> >>
> >>   Scrub device $dev2 (id 2) done
> >>   Scrub started:    Tue Jun  6 09:59:14 2023
> >>   Status:           finished
> >>   Duration:         0:00:00
> >> 	[...]
> >>   	corrected_errors: 16 <<< Still has corrupted sectors
> >>   	last_physical: 1351614464
> >>
> >>   # btrfs scrub start -BrRd $mnt
> >>   Scrub device $dev1 (id 1) done
> >>   Scrub started:    Tue Jun  6 10:00:17 2023
> >>   Status:           finished
> >>   Duration:         0:00:00
> >> 	[...]
> >>   	corrected_errors: 0 <<< No more errors
> >>   	last_physical: 1372585984
> >>
> >>   Scrub device $dev2 (id 2) done
> >> 	[...]
> >>   	corrected_errors: 0 <<< No more errors
> >>   	last_physical: 1372585984
> >>
> >> [CAUSE]
> >> In the newly reworked scrub code, repair is always submitted no matter
> >> if we're doing a read-only scrub.
> >>
> >> [FIX]
> >> Fix it by skipping the write submission if the scrub is a read-only one.
> >>
> >> Unfortunately for the report part, even for a read-only scrub we will
> >> still report it as corrected errors, as we know it's repairable, even we
> >> won't really submit the write.
> > 
> > We can maybe present the results in scrub status in an different way
> > when it's started as read-only, e.g. not to say "repaired" but
> > "repairable (read-only)".
> 
> Yes, this is much better for end users.
> 
> But unfortunately we're still introducing a behavior change, even it's 
> just the report part.
> 
> Before the rework, read-only scrub would only report errors, no 
> repairable/correctable checks, thus it would report csum_errors=32 and 
> corrected_errors=0 for example.
> 
> Now we will report csum_errors=32 and corrected_errors=32.
> 
> With progs changes, it would be an improvement, but still a behavior change.

Sometimes we need to do such changes, I don't treat report as an ABI but
at least the negative impact should be minimized. If the before/after
can be recognized it's still better than printing the same information
with a different meaning.

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

* Re: [PATCH] btrfs: scrub: respect the read-only flag during repair
  2023-06-08 11:56 ` David Sterba
@ 2023-06-08 12:08   ` Qu Wenruo
  2023-06-08 12:07     ` David Sterba
  0 siblings, 1 reply; 4+ messages in thread
From: Qu Wenruo @ 2023-06-08 12:08 UTC (permalink / raw)
  To: dsterba; +Cc: linux-btrfs



On 2023/6/8 19:56, David Sterba wrote:
> On Tue, Jun 06, 2023 at 10:05:04AM +0800, Qu Wenruo wrote:
>> [BUG]
>> With recent scrub rework, the scrub operation no longer respects the
>> read-only flag passed by "-r" option of "btrfs scrub start" command.
>>
>>   # mkfs.btrfs -f -d raid1 $dev1 $dev2
>>   # mount $dev1 $mnt
>>   # xfs_io -f -d -c "pwrite -b 128K -S 0xaa 0 128k" $mnt/file
>>   # sync
>>   # xfs_io -c "pwrite -S 0xff $phy1 64k" $dev1
>>   # xfs_io -c "pwrite -S 0xff $((phy2 + 65536)) 64k" $dev2
>>   # mount $dev1 $mnt -o ro
>>   # btrfs scrub start -BrRd $mnt
>>   Scrub device $dev1 (id 1) done
>>   Scrub started:    Tue Jun  6 09:59:14 2023
>>   Status:           finished
>>   Duration:         0:00:00
>> 	[...]
>>   	corrected_errors: 16 <<< Still has corrupted sectors
>>   	last_physical: 1372585984
>>
>>   Scrub device $dev2 (id 2) done
>>   Scrub started:    Tue Jun  6 09:59:14 2023
>>   Status:           finished
>>   Duration:         0:00:00
>> 	[...]
>>   	corrected_errors: 16 <<< Still has corrupted sectors
>>   	last_physical: 1351614464
>>
>>   # btrfs scrub start -BrRd $mnt
>>   Scrub device $dev1 (id 1) done
>>   Scrub started:    Tue Jun  6 10:00:17 2023
>>   Status:           finished
>>   Duration:         0:00:00
>> 	[...]
>>   	corrected_errors: 0 <<< No more errors
>>   	last_physical: 1372585984
>>
>>   Scrub device $dev2 (id 2) done
>> 	[...]
>>   	corrected_errors: 0 <<< No more errors
>>   	last_physical: 1372585984
>>
>> [CAUSE]
>> In the newly reworked scrub code, repair is always submitted no matter
>> if we're doing a read-only scrub.
>>
>> [FIX]
>> Fix it by skipping the write submission if the scrub is a read-only one.
>>
>> Unfortunately for the report part, even for a read-only scrub we will
>> still report it as corrected errors, as we know it's repairable, even we
>> won't really submit the write.
> 
> We can maybe present the results in scrub status in an different way
> when it's started as read-only, e.g. not to say "repaired" but
> "repairable (read-only)".

Yes, this is much better for end users.

But unfortunately we're still introducing a behavior change, even it's 
just the report part.

Before the rework, read-only scrub would only report errors, no 
repairable/correctable checks, thus it would report csum_errors=32 and 
corrected_errors=0 for example.

Now we will report csum_errors=32 and corrected_errors=32.

With progs changes, it would be an improvement, but still a behavior change.


BTW, the rework also fixed a report bug (I didn't even notice), that 
csum_discards is incorrectly reported before the rework.

But I guess no one even noticed anyway...

Thanks,
Qu

> 
>> Fixes: e02ee89baa66 ("btrfs: scrub: switch scrub_simple_mirror() to scrub_stripe infrastructure")
>> Signed-off-by: Qu Wenruo <wqu@suse.com>
> 
> Added to misc-next, thanks.

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

end of thread, other threads:[~2023-06-08 12:13 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2023-06-06  2:05 [PATCH] btrfs: scrub: respect the read-only flag during repair Qu Wenruo
2023-06-08 11:56 ` David Sterba
2023-06-08 12:08   ` Qu Wenruo
2023-06-08 12:07     ` 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.