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?
kdave
commented
4 weeks ago
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?