@@ -29,7 +29,7 @@
#include "common/utils.h"
#include "tune/tune.h"
-static int check_csum_change_requreiment(struct btrfs_fs_info *fs_info)
+static int check_csum_change_requreiment(struct btrfs_fs_info *fs_info, u16 new_csum_type)
{
struct btrfs_root *tree_root = fs_info->tree_root;
struct btrfs_root *dev_root = fs_info->dev_root;
@@ -75,6 +75,12 @@ static int check_csum_change_requreiment(struct btrfs_fs_info *fs_info)
error("running dev-replace detected, please finish or cancel it.");
return -EINVAL;
}
+
+ if (fs_info->csum_type == new_csum_type) {
+ error("the fs is already using csum type %s (%u)",
+ btrfs_super_csum_name(new_csum_type), new_csum_type);
+ return -EINVAL;
+ }
return 0;
}
@@ -1001,7 +1007,7 @@ int btrfs_change_csum_type(struct btrfs_fs_info *fs_info, u16 new_csum_type)
int ret;
/* Phase 0, check conflicting features. */
- ret = check_csum_change_requreiment(fs_info);
+ ret = check_csum_change_requreiment(fs_info, new_csum_type);
if (ret < 0)
return ret;
Currently "btrfstune --csum" allows us to change the csum to the same one, this is good for testing but not good for end users, as if the end user interrupts it, they have to resume the change (even it's to the same csum type) until it finished, or kernel would reject such fs. Furthermore, we never change the super block csum type until we completely changed the csum type, thus for resume cases, the fs would still show up as using the old csum type thus won't cause any problem resuming. So here we just reject the csum conversion if the target csum type is the same as the existing csum type. Signed-off-by: Qu Wenruo <wqu@suse.com> --- tune/change-csum.c | 10 ++++++++-- 1 file changed, 8 insertions(+), 2 deletions(-)