* [PATCH v2 1/2] btrfs-progs: warn users about the possible dangers of check --repair
@ 2019-10-18 11:16 Johannes Thumshirn
2019-10-18 11:16 ` [PATCH v2 2/2] btrfs-progs: docs: fix warning test Johannes Thumshirn
` (2 more replies)
0 siblings, 3 replies; 9+ messages in thread
From: Johannes Thumshirn @ 2019-10-18 11:16 UTC (permalink / raw)
To: David Sterba
Cc: Nikolay Borisov, quwenruo.btrfs, anand.jain, rbrown,
Linux BTRFS Mailinglist, Johannes Thumshirn
The manual page of btrfsck clearly states 'btrfs check --repair' is a
dangerous operation.
Although this warning is in place users do not read the manual page and/or
are used to the behaviour of fsck utilities which repair the filesystem,
and thus potentially cause harm.
Similar to 'btrfs balance' without any filters, add a warning and a
countdown, so users can bail out before eventual corrupting the filesystem
more than it already is.
Signed-off-by: Johannes Thumshirn <jthumshirn@suse.de>
---
Changes to v1:
- Fix grammar mistakes in warning message
- Skip delay with --force
- Adjust tests to cope with btrfsck --repair --force
---
check/main.c | 23 ++++++++++++++++------
tests/cli-tests/007-check-force/test.sh | 2 --
tests/fsck-tests/013-extent-tree-rebuild/test.sh | 2 +-
tests/fsck-tests/032-corrupted-qgroup/test.sh | 2 +-
tests/fuzz-tests/003-multi-check-unmounted/test.sh | 2 +-
5 files changed, 20 insertions(+), 11 deletions(-)
diff --git a/check/main.c b/check/main.c
index fd05430c1f51..1fecfc37c135 100644
--- a/check/main.c
+++ b/check/main.c
@@ -9970,6 +9970,23 @@ static int cmd_check(const struct cmd_struct *cmd, int argc, char **argv)
exit(1);
}
+ if (repair && !force) {
+ int delay = 10;
+ printf("WARNING:\n\n");
+ printf("\tDo not use --repair unless you are advised to do so by a developer\n");
+ printf("\tor an experienced user, and then only after having accepted that no\n");
+ printf("\tfsck can successfully repair all types of filesystem corruption. Eg.\n");
+ printf("\tsome software or hardware bugs can fatally damage a volume.\n");
+ printf("\tThe operation will start in %d seconds.\n", delay);
+ printf("\tUse Ctrl-C to stop it.\n");
+ while (delay) {
+ printf("%2d", delay--);
+ fflush(stdout);
+ sleep(1);
+ }
+ printf("\nStarting repair.\n");
+ }
+
/*
* experimental and dangerous
*/
@@ -9998,12 +10015,6 @@ static int cmd_check(const struct cmd_struct *cmd, int argc, char **argv)
goto err_out;
}
} else {
- if (repair) {
- error("repair and --force is not yet supported");
- ret = 1;
- err |= !!ret;
- goto err_out;
- }
if (ret < 0) {
warning(
"cannot check mount status of %s, the filesystem could be mounted, continuing because of --force",
diff --git a/tests/cli-tests/007-check-force/test.sh b/tests/cli-tests/007-check-force/test.sh
index 317b8cf42f83..6025b8545c52 100755
--- a/tests/cli-tests/007-check-force/test.sh
+++ b/tests/cli-tests/007-check-force/test.sh
@@ -26,7 +26,5 @@ run_mustfail "checking mounted filesystem with --force --repair" \
run_check_umount_test_dev
run_check $SUDO_HELPER "$TOP/btrfs" check "$TEST_DEV"
run_check $SUDO_HELPER "$TOP/btrfs" check --force "$TEST_DEV"
-run_mustfail "--force --repair on unmounted filesystem" \
- $SUDO_HELPER "$TOP/btrfs" check --force --repair "$TEST_DEV"
cleanup_loopdevs
diff --git a/tests/fsck-tests/013-extent-tree-rebuild/test.sh b/tests/fsck-tests/013-extent-tree-rebuild/test.sh
index ac5a406a8b8a..33beb8bf55b4 100755
--- a/tests/fsck-tests/013-extent-tree-rebuild/test.sh
+++ b/tests/fsck-tests/013-extent-tree-rebuild/test.sh
@@ -35,7 +35,7 @@ test_extent_tree_rebuild()
$SUDO_HELPER "$TOP/btrfs" check "$TEST_DEV" >& /dev/null && \
_fail "btrfs check should detect failure"
- run_check $SUDO_HELPER "$TOP/btrfs" check --repair --init-extent-tree "$TEST_DEV"
+ run_check $SUDO_HELPER "$TOP/btrfs" check --repair --force --init-extent-tree "$TEST_DEV"
run_check $SUDO_HELPER "$TOP/btrfs" check "$TEST_DEV"
}
diff --git a/tests/fsck-tests/032-corrupted-qgroup/test.sh b/tests/fsck-tests/032-corrupted-qgroup/test.sh
index 4bfa36013e81..91bbd51a4ebd 100755
--- a/tests/fsck-tests/032-corrupted-qgroup/test.sh
+++ b/tests/fsck-tests/032-corrupted-qgroup/test.sh
@@ -13,7 +13,7 @@ check_image() {
"$TOP/btrfs" check "$1"
# Above command can fail due to other bugs, so add extra check to
# ensure we can fix qgroup without problems.
- run_check "$TOP/btrfs" check --repair "$1"
+ run_check "$TOP/btrfs" check --repair --force "$1"
}
check_all_images
diff --git a/tests/fuzz-tests/003-multi-check-unmounted/test.sh b/tests/fuzz-tests/003-multi-check-unmounted/test.sh
index 3021c3a84968..176272e508d7 100755
--- a/tests/fuzz-tests/003-multi-check-unmounted/test.sh
+++ b/tests/fuzz-tests/003-multi-check-unmounted/test.sh
@@ -18,7 +18,7 @@ check_image() {
run_mayfail $TOP/btrfs check --init-extent-tree "$image"
run_mayfail $TOP/btrfs check --check-data-csum "$image"
run_mayfail $TOP/btrfs check --subvol-extents "$image"
- run_mayfail $TOP/btrfs check --repair "$image"
+ run_mayfail $TOP/btrfs check --repair --force "$image"
}
check_all_images "$TEST_TOP/fuzz-tests/images"
--
2.16.4
^ permalink raw reply related [flat|nested] 9+ messages in thread
* [PATCH v2 2/2] btrfs-progs: docs: fix warning test
2019-10-18 11:16 [PATCH v2 1/2] btrfs-progs: warn users about the possible dangers of check --repair Johannes Thumshirn
@ 2019-10-18 11:16 ` Johannes Thumshirn
2019-10-21 15:22 ` [PATCH v2 1/2] btrfs-progs: warn users about the possible dangers of check --repair David Sterba
2019-11-15 12:53 ` David Sterba
2 siblings, 0 replies; 9+ messages in thread
From: Johannes Thumshirn @ 2019-10-18 11:16 UTC (permalink / raw)
To: David Sterba
Cc: Nikolay Borisov, quwenruo.btrfs, anand.jain, rbrown,
Linux BTRFS Mailinglist, Johannes Thumshirn
The warning about the dangers of repair was lacking a bit grammatically odd.
Fix it to read more naturally.
Signed-off-by: Johannes Thumshirn <jthumshirn@suse.de>
---
Documentation/btrfs-check.asciidoc | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/Documentation/btrfs-check.asciidoc b/Documentation/btrfs-check.asciidoc
index b963eae5cdce..1a4d8167ccba 100644
--- a/Documentation/btrfs-check.asciidoc
+++ b/Documentation/btrfs-check.asciidoc
@@ -23,8 +23,8 @@ by the option '--readonly'.
*btrfsck* is an alias of *btrfs check* command and is now deprecated.
WARNING: Do not use '--repair' unless you are advised to do so by a developer
-or an experienced user, and then only after having accepted that no 'fsck'
-successfully repair all types of filesystem corruption. Eg. some other software
+or an experienced user, and then only after having accepted that no 'fsck' can
+successfully repair all types of filesystem corruption. Eg. some software
or hardware bugs can fatally damage a volume.
The structural integrity check verifies if internal filesystem objects or
--
2.16.4
^ permalink raw reply related [flat|nested] 9+ messages in thread
* Re: [PATCH v2 1/2] btrfs-progs: warn users about the possible dangers of check --repair
2019-10-18 11:16 [PATCH v2 1/2] btrfs-progs: warn users about the possible dangers of check --repair Johannes Thumshirn
2019-10-18 11:16 ` [PATCH v2 2/2] btrfs-progs: docs: fix warning test Johannes Thumshirn
@ 2019-10-21 15:22 ` David Sterba
2019-10-22 7:33 ` Johannes Thumshirn
2019-11-15 12:53 ` David Sterba
2 siblings, 1 reply; 9+ messages in thread
From: David Sterba @ 2019-10-21 15:22 UTC (permalink / raw)
To: Johannes Thumshirn
Cc: David Sterba, Nikolay Borisov, quwenruo.btrfs, anand.jain,
rbrown, Linux BTRFS Mailinglist
On Fri, Oct 18, 2019 at 01:16:03PM +0200, Johannes Thumshirn wrote:
> The manual page of btrfsck clearly states 'btrfs check --repair' is a
> dangerous operation.
>
> Although this warning is in place users do not read the manual page and/or
> are used to the behaviour of fsck utilities which repair the filesystem,
> and thus potentially cause harm.
>
> Similar to 'btrfs balance' without any filters, add a warning and a
> countdown, so users can bail out before eventual corrupting the filesystem
> more than it already is.
>
> Signed-off-by: Johannes Thumshirn <jthumshirn@suse.de>
>
> ---
> Changes to v1:
> - Fix grammar mistakes in warning message
> - Skip delay with --force
--force was added for a different reason, to allow check on a mounted
filesystem. I don't think that combining --repair and --force just to
allow repair is a good idea. There's a 'dangerous repair' mode for eg.
xfs that allows to do live surgery on a mounted filesytem (followed by
immediate reboot). We want to be able to do that eventually.
I understand where the motivation comes from, let me have a second
thought on that.
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [PATCH v2 1/2] btrfs-progs: warn users about the possible dangers of check --repair
2019-10-21 15:22 ` [PATCH v2 1/2] btrfs-progs: warn users about the possible dangers of check --repair David Sterba
@ 2019-10-22 7:33 ` Johannes Thumshirn
2019-10-22 7:37 ` Qu Wenruo
2019-10-22 12:19 ` David Sterba
0 siblings, 2 replies; 9+ messages in thread
From: Johannes Thumshirn @ 2019-10-22 7:33 UTC (permalink / raw)
To: dsterba, David Sterba, Nikolay Borisov, quwenruo.btrfs,
anand.jain, rbrown, Linux BTRFS Mailinglist
On 21/10/2019 17:22, David Sterba wrote:
> --force was added for a different reason, to allow check on a mounted
> filesystem. I don't think that combining --repair and --force just to
> allow repair is a good idea. There's a 'dangerous repair' mode for eg.
> xfs that allows to do live surgery on a mounted filesytem (followed by
> immediate reboot). We want to be able to do that eventually.
>
> I understand where the motivation comes from, let me have a second
> thought on that.
So how about adding a '--yes' or '--accept', '--dangerous',
'--allow-dangeruos' parameter instead of force to skip the warning?
My vote would go for '--allow-dangerous'.
Byte,
Johannes
--
Johannes Thumshirn SUSE Labs Filesystems
jthumshirn@suse.de +49 911 74053 689
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5
90409 Nürnberg
Germany
(HRB 36809, AG Nürnberg)
Geschäftsführer: Felix Imendörffer
Key fingerprint = EC38 9CAB C2C4 F25D 8600 D0D0 0393 969D 2D76 0850
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [PATCH v2 1/2] btrfs-progs: warn users about the possible dangers of check --repair
2019-10-22 7:33 ` Johannes Thumshirn
@ 2019-10-22 7:37 ` Qu Wenruo
2019-10-22 7:45 ` Johannes Thumshirn
2019-10-22 7:50 ` Nikolay Borisov
2019-10-22 12:19 ` David Sterba
1 sibling, 2 replies; 9+ messages in thread
From: Qu Wenruo @ 2019-10-22 7:37 UTC (permalink / raw)
To: Johannes Thumshirn, dsterba, David Sterba, Nikolay Borisov,
anand.jain, rbrown, Linux BTRFS Mailinglist
On 2019/10/22 下午3:33, Johannes Thumshirn wrote:
> On 21/10/2019 17:22, David Sterba wrote:
>> --force was added for a different reason, to allow check on a mounted
>> filesystem. I don't think that combining --repair and --force just to
>> allow repair is a good idea. There's a 'dangerous repair' mode for eg.
>> xfs that allows to do live surgery on a mounted filesytem (followed by
>> immediate reboot). We want to be able to do that eventually.
>>
>> I understand where the motivation comes from, let me have a second
>> thought on that.
>
> So how about adding a '--yes' or '--accept', '--dangerous',
> '--allow-dangeruos' parameter instead of force to skip the warning?
>
> My vote would go for '--allow-dangerous'.
+1 for '--yes', at least e2fsck has a similar '-y' option.
Thanks,
Qu
>
> Byte,
> Johannes
>
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [PATCH v2 1/2] btrfs-progs: warn users about the possible dangers of check --repair
2019-10-22 7:37 ` Qu Wenruo
@ 2019-10-22 7:45 ` Johannes Thumshirn
2019-10-22 7:50 ` Nikolay Borisov
1 sibling, 0 replies; 9+ messages in thread
From: Johannes Thumshirn @ 2019-10-22 7:45 UTC (permalink / raw)
To: Qu Wenruo, dsterba, David Sterba, Nikolay Borisov, anand.jain,
rbrown, Linux BTRFS Mailinglist
On 22/10/2019 09:37, Qu Wenruo wrote:
> +1 for '--yes', at least e2fsck has a similar '-y' option.
OK, for me as well. And yes being in line with e2fsck has it's benefits
as well.
Byte,
Johannes
--
Johannes Thumshirn SUSE Labs Filesystems
jthumshirn@suse.de +49 911 74053 689
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5
90409 Nürnberg
Germany
(HRB 36809, AG Nürnberg)
Geschäftsführer: Felix Imendörffer
Key fingerprint = EC38 9CAB C2C4 F25D 8600 D0D0 0393 969D 2D76 0850
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [PATCH v2 1/2] btrfs-progs: warn users about the possible dangers of check --repair
2019-10-22 7:37 ` Qu Wenruo
2019-10-22 7:45 ` Johannes Thumshirn
@ 2019-10-22 7:50 ` Nikolay Borisov
1 sibling, 0 replies; 9+ messages in thread
From: Nikolay Borisov @ 2019-10-22 7:50 UTC (permalink / raw)
To: Qu Wenruo, Johannes Thumshirn, dsterba, David Sterba, anand.jain,
rbrown, Linux BTRFS Mailinglist
On 22.10.19 г. 10:37 ч., Qu Wenruo wrote:
>
>
> On 2019/10/22 下午3:33, Johannes Thumshirn wrote:
>> On 21/10/2019 17:22, David Sterba wrote:
>>> --force was added for a different reason, to allow check on a mounted
>>> filesystem. I don't think that combining --repair and --force just to
>>> allow repair is a good idea. There's a 'dangerous repair' mode for eg.
>>> xfs that allows to do live surgery on a mounted filesytem (followed by
>>> immediate reboot). We want to be able to do that eventually.
>>>
>>> I understand where the motivation comes from, let me have a second
>>> thought on that.
>>
>> So how about adding a '--yes' or '--accept', '--dangerous',
>> '--allow-dangeruos' parameter instead of force to skip the warning?
>>
>> My vote would go for '--allow-dangerous'.
>
> +1 for '--yes', at least e2fsck has a similar '-y' option.
I'\m fine with --yes/-y. It's not just e2fsck but I've seen similar
options in other tools as well.
>
> Thanks,
> Qu
>
>>
>> Byte,
>> Johannes
>>
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [PATCH v2 1/2] btrfs-progs: warn users about the possible dangers of check --repair
2019-10-22 7:33 ` Johannes Thumshirn
2019-10-22 7:37 ` Qu Wenruo
@ 2019-10-22 12:19 ` David Sterba
1 sibling, 0 replies; 9+ messages in thread
From: David Sterba @ 2019-10-22 12:19 UTC (permalink / raw)
To: Johannes Thumshirn
Cc: dsterba, David Sterba, Nikolay Borisov, quwenruo.btrfs,
anand.jain, rbrown, Linux BTRFS Mailinglist
On Tue, Oct 22, 2019 at 09:33:06AM +0200, Johannes Thumshirn wrote:
> On 21/10/2019 17:22, David Sterba wrote:
> > --force was added for a different reason, to allow check on a mounted
> > filesystem. I don't think that combining --repair and --force just to
> > allow repair is a good idea. There's a 'dangerous repair' mode for eg.
> > xfs that allows to do live surgery on a mounted filesytem (followed by
> > immediate reboot). We want to be able to do that eventually.
> >
> > I understand where the motivation comes from, let me have a second
> > thought on that.
>
> So how about adding a '--yes' or '--accept', '--dangerous',
> '--allow-dangeruos' parameter instead of force to skip the warning?
>
> My vote would go for '--allow-dangerous'.
So, I agree with the above. The dangerous repair should be something
almost nobody does or should do, so a very long option name is just
fine. This leaves -f for --repair to skip the warning. We now have:
* btrfs check - read-only by default, no changes
* btrfs check --read-only - same as above, explicit about RO
* btrfs check --repair - warning with a timeout, then repair
* btrfs check --repair -f - no warning (or the warning could be still
printed but without timeout)
I'd rather avoid options that would be confusing to what are they
referring to. So '--yes' it's like don't ask questions before repairing,
that's what e2fsck does but that's different from the initial warning.
And so on.
The dangerous repair would need a full set of the options, so
* btrfs --repair -f --allow-dangerous
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [PATCH v2 1/2] btrfs-progs: warn users about the possible dangers of check --repair
2019-10-18 11:16 [PATCH v2 1/2] btrfs-progs: warn users about the possible dangers of check --repair Johannes Thumshirn
2019-10-18 11:16 ` [PATCH v2 2/2] btrfs-progs: docs: fix warning test Johannes Thumshirn
2019-10-21 15:22 ` [PATCH v2 1/2] btrfs-progs: warn users about the possible dangers of check --repair David Sterba
@ 2019-11-15 12:53 ` David Sterba
2 siblings, 0 replies; 9+ messages in thread
From: David Sterba @ 2019-11-15 12:53 UTC (permalink / raw)
To: Johannes Thumshirn
Cc: David Sterba, Nikolay Borisov, quwenruo.btrfs, anand.jain,
rbrown, Linux BTRFS Mailinglist
On Fri, Oct 18, 2019 at 01:16:03PM +0200, Johannes Thumshirn wrote:
> The manual page of btrfsck clearly states 'btrfs check --repair' is a
> dangerous operation.
>
> Although this warning is in place users do not read the manual page and/or
> are used to the behaviour of fsck utilities which repair the filesystem,
> and thus potentially cause harm.
>
> Similar to 'btrfs balance' without any filters, add a warning and a
> countdown, so users can bail out before eventual corrupting the filesystem
> more than it already is.
>
> Signed-off-by: Johannes Thumshirn <jthumshirn@suse.de>
For the record, this is on the way to 5.4. Thanks.
^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2019-11-15 12:53 UTC | newest]
Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-10-18 11:16 [PATCH v2 1/2] btrfs-progs: warn users about the possible dangers of check --repair Johannes Thumshirn
2019-10-18 11:16 ` [PATCH v2 2/2] btrfs-progs: docs: fix warning test Johannes Thumshirn
2019-10-21 15:22 ` [PATCH v2 1/2] btrfs-progs: warn users about the possible dangers of check --repair David Sterba
2019-10-22 7:33 ` Johannes Thumshirn
2019-10-22 7:37 ` Qu Wenruo
2019-10-22 7:45 ` Johannes Thumshirn
2019-10-22 7:50 ` Nikolay Borisov
2019-10-22 12:19 ` David Sterba
2019-11-15 12:53 ` David Sterba
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).