[0/2] btrfs-progs: btrfstune: fix false alerts on dev-replace when changing csum

Message

Qu Wenruo June 2, 2024, 3:45 a.m. UTC

There is a bug report that if a btrfs has experienced any dev-replace,
"btrfstune --csum" would always report a running dev-replace and refuse
to continue.

It turns out that, DEV_REPLACE item is not a transient one (but not
created properly as mkfs time either), after a dev-replace the
DEV_REPLACE item would exist forever, recording the last dev-replace
timestamp.

Although I really hate such behavior (especially when balance item would
be gone after a balance is finished/canceled), at least fix the problem
first.

The first patch enhances the print-tree to properly output the
contents of the dev-replace item, then the second patch fixes the
problem.

I'd like to add test cases for it, but it turns out there is no csum
change test cases.
My guess is we do not have proper way to skip the test if it's
experiemental feature?

Maybe it's time to move csum change out of experiemental features?

Qu Wenruo (2):
  btrfs-progs: print-tree: add support for dev-replace item
  btrfs-progs: change-csum: handle finished dev-replace correctly

 kernel-shared/print-tree.c | 79 ++++++++++++++++++++++++++++++++++++++
 tune/change-csum.c         | 18 +++++++--
 2 files changed, 94 insertions(+), 3 deletions(-)

--
2.45.1

Comments

David Sterba June 3, 2024, 7:57 p.m. UTC | #1

On Sun, Jun 02, 2024 at 01:15:31PM +0930, Qu Wenruo wrote:
> There is a bug report that if a btrfs has experienced any dev-replace,
> "btrfstune --csum" would always report a running dev-replace and refuse
> to continue.
> 
> It turns out that, DEV_REPLACE item is not a transient one (but not
> created properly as mkfs time either), after a dev-replace the
> DEV_REPLACE item would exist forever, recording the last dev-replace
> timestamp.

I don't think we want to create the item at mkfs time, this would be
confusing and not related to any previous dev-replace operation.

> Although I really hate such behavior (especially when balance item would
> be gone after a balance is finished/canceled), at least fix the problem
> first.

It's handled differently yeah, though the two operations are bit
different, one would run balance more often that dev-replace. But it's
still only for internal tracking, other than that it's not handled the
same way I don't se any problem.

> The first patch enhances the print-tree to properly output the
> contents of the dev-replace item, then the second patch fixes the
> problem.
> 
> I'd like to add test cases for it, but it turns out there is no csum
> change test cases.

I have tests locally from the time I developed it but yeah they should
be in the testsuite.

> My guess is we do not have proper way to skip the test if it's
> experiemental feature?

Currently there's no way to detect it. For some things we can use the
help text, like is done for some features in fstests.

> Maybe it's time to move csum change out of experiemental features?

This depends on creating the separate command group 'tune', this is in
the phase of interface review.

> Qu Wenruo (2):
>   btrfs-progs: print-tree: add support for dev-replace item
>   btrfs-progs: change-csum: handle finished dev-replace correctly

Added to devel, thanks.