From: Graham Cobb <g.btrfs@cobb.uk.net>
To: Qu Wenruo <quwenruo.btrfs@gmx.com>,
Josef Bacik <josef@toxicpanda.com>,
linux-btrfs@vger.kernel.org, kernel-team@fb.com
Subject: Re: [PATCH][v2] btrfs: introduce rescue=onlyfs
Date: Wed, 22 Jul 2020 10:36:21 +0100 [thread overview]
Message-ID: <b36ef7ea-fff2-6828-a6dc-4abcb4f2afff@cobb.uk.net> (raw)
In-Reply-To: <cd1ec35d-e9ac-6cee-e0af-d1ecdc111e1e@gmx.com>
On 22/07/2020 00:05, Qu Wenruo wrote:
>
>
> On 2020/7/21 下午11:10, Josef Bacik wrote:
...
>> - skip_sum = BTRFS_I(inode)->flags & BTRFS_INODE_NODATASUM;
>> + skip_sum = (BTRFS_I(inode)->flags & BTRFS_INODE_NODATASUM) ||
>> + btrfs_test_opt(fs_info, ONLYFS);
>
> This means, if onlyfs is spcified, csum is completely skipped even it
> matches.
>
> I'm not yet determined whether it's preferred.
>
> On one hand, even at recovery, user may want csum verification to detect
> bad copy if possible, but on the other hand, since user is doing data
> salvage, bothering csum could only lead to extra error.
If we are using this option then something very bad has happened to the
filesystem. It would be useful to the user to know whether the checksum
on the file being read is valid or not as a failed checksum will be a
hint that the BAD THING has affected this file (maybe some extent got
incorrectly overwritten by the content of another file, for example). It
would tell the user that they may want to check the file in some other
way or, at least, not rely on its contents.
On the other hand, it may be that the file contents are fine, but the
checksum has been corrupted, so it should also be possible the retrieve
the contents anyway.
Of course, in the face of unknown filesystem corruption, a valid
checksum does not guarantee that the file is uncorrupted. But a bad
checksum gives a strong hint that the file needs additional checking.
I don't particularly care how the user finds out that the checksum is
bad. In my earlier mail, I suggested that this option does not imply
nodatasum and that the user has to specify nodatasum if that is what
they want. However, I would also be happy with (for example) a warning
in the logs if the checksum is not valid.
By the way, is it possible to do a scrub while the filesystem is mounted
with this option? What would happen, in that case, for either real bad
sectors or checksum errors caused by the filesystem corruption?
prev parent reply other threads:[~2020-07-22 9:36 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-07-21 15:10 [PATCH][v2] btrfs: introduce rescue=onlyfs Josef Bacik
2020-07-21 15:56 ` Graham Cobb
2020-07-21 17:16 ` David Sterba
2020-07-21 17:25 ` Josef Bacik
2020-07-21 21:20 ` Chris Murphy
2020-07-21 17:34 ` Graham Cobb
2020-07-21 17:40 ` Josef Bacik
2020-07-21 21:25 ` Chris Murphy
2020-07-21 23:05 ` Qu Wenruo
2020-07-22 9:36 ` Graham Cobb [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=b36ef7ea-fff2-6828-a6dc-4abcb4f2afff@cobb.uk.net \
--to=g.btrfs@cobb.uk.net \
--cc=josef@toxicpanda.com \
--cc=kernel-team@fb.com \
--cc=linux-btrfs@vger.kernel.org \
--cc=quwenruo.btrfs@gmx.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox