btrfs-progs: check: Make btrfs check return error for qgroup mismatch
PATCH 1/2 btrfs-progs: check: Make btrfs check return error for qgroup mismatch
Current btrfs-check will check qgroup consistency, but even when it finds something wrong, the return value is still 0.
Fix it by allowing report_qgroups() to return int to indicate qgroup mismatch, and also add extra logical to return no error if qgroup repair is successful.
Without this patch, fstests can't detect qgroup corruption by its fsck alone.
--- check/main.c | 10 ++++++---- qgroup-verify.c | 20 +++++++++++++++++--- qgroup-verify.h | 2 +- 3 files changed, 24 insertions(+), 8 deletions(-)
check/main.c +6 -4
@@ -9467,6 +9467,7 @@ int cmd_check(int argc, char **argv)int clear_space_cache =0 ;int qgroup_report =0 ;int qgroups_repaired =0 ; +int qgroup_report_ret;unsigned ctree_flags =OPEN_CTREE_EXCLUSIVE ;int force =0 ;
@@ -9709,7 +9710,7 @@ int cmd_check(int argc, char **argv) ret =qgroup_verify_all (info); err |= !!ret;if (ret ==0 ) -report_qgroups (1 ); + err |= !!report_qgroups (1 ); goto close_out; }if (subvolid) {
@@ -9894,13 +9895,14 @@ int cmd_check(int argc, char **argv)error ("failed to check quota groups" ); goto out; } -report_qgroups (0 ); + qgroup_report_ret =report_qgroups (0 ); ret =repair_qgroups (info, &qgroups_repaired); - err |= !!ret; -if (err) { +if (ret) {error ("failed to repair quota groups" ); goto out; } +if (qgroup_report_ret && (!qgroups_repaired || ret)) + err |= qgroup_report_ret; ret =0 ; }
qgroup-verify.c +17 -3
@@ -1298,10 +1298,19 @@ static int report_qgroup_difference(struct qgroup_count *count, int verbose)return is_different; } -void report_qgroups (int all) +/* +* Report qgroups errors +* Return 0 if nothing wrong. +* Return <0 if any qgroup is inconsistent. +* +* @all: if set, all qgroup will be checked and reported even already +* inconsistent or under rescan. +*/ +int report_qgroups (int all) {struct rb_node *node;struct qgroup_count *c; +bool found_err = false;if (!repair && counts.rescan_running) {if (all) {
@@ -1310,7 +1319,7 @@ void report_qgroups(int all) }else {printf ("Qgroup rescan is running, qgroups will not be printed.\n" ); -return ; +return 0 ; } }if (counts.qgroup_inconsist && !counts.rescan_running)
@@ -1319,11 +1328,16 @@ void report_qgroups(int all)while (node) { c = rb_entry(node, struct qgroup_count, rb_node); -if (report_qgroup_difference (c, all)) +if (report_qgroup_difference (c, all)) {list_add_tail (&c->bad_list, &bad_qgroups); + found_err = true; + } node =rb_next (node); } +if (found_err) +return -EUCLEAN ; +return 0 ; }void free_qgroup_counts (void )
qgroup-verify.h +1 -1
@@ -23,7 +23,7 @@#include "ctree.h" int qgroup_verify_all (struct btrfs_fs_info *info); -void report_qgroups (int all); +int report_qgroups (int all);int repair_qgroups (struct btrfs_fs_info *info,int *repaired);int print_extent_state (struct btrfs_fs_info *info,u64 subvol);
Signature · 1 line
2.17.0
PATCH 2/2 btrfs-progs: fsck-tests: Add test case to ensure btrfs check return error for corrupted qgroups
Since the test case uses run_mustfail(), which is pretty easy pass due to other unexpected problems, so here an extra run_check() is added to ensure we don't only report qgroup error, but also fix it without problem.
--- .../032-corrupted-qgroup/qgroup_corrupted.img | Bin 0 -> 3072 bytes tests/fsck-tests/032-corrupted-qgroup/test.sh | 19 ++++++++++++++++++ 2 files changed, 19 insertions(+) create mode 100644 tests/fsck-tests/032-corrupted-qgroup/qgroup_corrupted.img create mode 100755 tests/fsck-tests/032-corrupted-qgroup/test.sh
tests/fsck-tests/032-corrupted-qgroup/qgroup_corrupted.img new file binary +0 -0
tests/fsck-tests/032-corrupted-qgroup/test.sh new file +19 -0
@@ -0,0 +1,19 @@ +#!/bin/bash +# To check if btrfs check can handle valid orphan items. +# Orphan item is a marker for deleted inodes that were open at the time of +# deletion. # Orphan inode/root will is not referenced and will have an orphan +# item, which should not be reported as error. + +source "$TEST_TOP/common" + +check_prereq btrfs + +check_image() { + run_mustfail "btrfs check failed to detect qgroup corruption" \ + "$TOP/btrfs" check "$1" + # Above command can fail due to other bugs, so add extra safe net to + # ensure we can fix qgroup without problem. + run_check "$TOP/btrfs" check --repair "$1" +} + +check_all_images
Signature · 1 line
2.17.0
David Sterba
AppliedQuoted 11 lines · Qu Wenruo
Current btrfs-check will check qgroup consistency, but even when it finds something wrong, the return value is still 0.
Fix it by allowing
report_qgroups()to return int to indicate qgroup mismatch, and also add extra logical to return no error if qgroup repair is successful.Without this patch, fstests can't detect qgroup corruption by its fsck alone.
Signed-off-by Qu Wenruo <[email protected]>
Applied, thanks. Please send the 0/N (cover letter) mail even for 2-patch series.
Quoted 8 lines · David Sterba
Quoted 7 lines · Qu Wenruo
Current btrfs-check will check qgroup consistency, but even when it finds something wrong, the return value is still 0.
Fix it by allowing
report_qgroups()to return int to indicate qgroup mismatch, and also add extra logical to return no error if qgroup repair is successful.
Quoted 7 lines
Quoted 4 lines
Without this patch, fstests can't detect qgroup corruption by its fsck alone.
Signed-off-by Qu Wenruo <[email protected]>Applied, thanks. Please send the 0/N (cover letter) mail even for 2-patch series.
Any advice on the necessity of the cover letter?
Is cover letter highly recommended for any patches which have any dependency like the 2nd test case?
Thanks,
Qu
Quoted 5 lines
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Quoted 16 lines · Qu Wenruo
Quoted 13 lines · David Sterba
Quoted 11 lines · Qu Wenruo
Current btrfs-check will check qgroup consistency, but even when it finds something wrong, the return value is still 0.
Fix it by allowing
report_qgroups()to return int to indicate qgroup mismatch, and also add extra logical to return no error if qgroup repair is successful.Without this patch, fstests can't detect qgroup corruption by its fsck alone.
Signed-off-by Qu Wenruo <[email protected]>
Quoted 7 lines
Quoted 2 lines
Applied, thanks. Please send the 0/N (cover letter) mail even for 2-patch series.
Any advice on the necessity of the cover letter?
Is cover letter highly recommended for any patches which have any dependency like the 2nd test case?
The cover letter is a place where you can get feedback on the whole patchset, individual patches get the specific comments to the code.
A patchset makes a logical chunk of patches so the cover letter also serves as the high-level overview of the changes before I or others even start looking further.
I've seen other maintainers to prefer cover letters, but as this is not documented and not generally appreciated by developers, it needs to be stated. Developers who post patches frequently could help to improve the patch flow process, but lack of cover letter is not a big deal otherwise.
Quoted 32 lines · David Sterba
Quoted 16 lines · Qu Wenruo
Quoted 13 lines · David Sterba
Quoted 11 lines · Qu Wenruo
Current btrfs-check will check qgroup consistency, but even when it finds something wrong, the return value is still 0.
Fix it by allowing
report_qgroups()to return int to indicate qgroup mismatch, and also add extra logical to return no error if qgroup repair is successful.Without this patch, fstests can't detect qgroup corruption by its fsck alone.
Signed-off-by Qu Wenruo <[email protected]>Quoted 7 lines
Quoted 2 lines
Applied, thanks. Please send the 0/N (cover letter) mail even for 2-patch series.
Any advice on the necessity of the cover letter?
Is cover letter highly recommended for any patches which have any dependency like the 2nd test case?
The cover letter is a place where you can get feedback on the whole patchset, individual patches get the specific comments to the code.
A patchset makes a logical chunk of patches so the cover letter also serves as the high-level overview of the changes before I or others even start looking further.
Quoted 5 lines
I've seen other maintainers to prefer cover letters, but as this is not documented and not generally appreciated by developers, it needs to be stated. Developers who post patches frequently could help to improve the patch flow process, but lack of cover letter is not a big deal otherwise.
Much appreciated about the explain on this topic.
Personally I'm completely fine for cover letters, so I would take this method for later logically related patches.
Thanks,
Qu