linux-btrfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Duncan <1i5t5.duncan@cox.net>
To: linux-btrfs@vger.kernel.org
Subject: Re: 3.15-rc5 btrfs send/receive corruption errors? Does scrub
Date: Sun, 11 May 2014 03:09:03 +0000 (UTC)	[thread overview]
Message-ID: <pan$ca817$195609f1$cf655dea$2b05cd43@cox.net> (raw)
In-Reply-To: 20140510235717.GB15909@merlins.org

Marc MERLIN posted on Sat, 10 May 2014 16:57:18 -0700 as excerpted:

> So, does scrub actually make sure everything on my filesystem is sane,
> or can it miss some kinds of corruptions?

Catching it here as well as the other thread...

All scrub does is verify the checksum (and replace bad versions with good 
versions where there's a good copy available to do so).

Scrub does NOT detect or fix faulty logic bug writes that never-the-less 
were properly checksummed, as the checksums can be perfectly valid on 
entirely invalid (meta)data.

Using an example from recent US political history, it's as if someone 
recorded the head of the US NSA assuring congress that it did not 
knowingly collect data on US citizens in the generic case, when a few 
months later we found out it was doing just that.  Now if that recording 
was checksummed, that checksum will normally still verify just fine 
today, even tho we know the claims in the recorded stream are 100% 
faulty.  Verifying the checksum can validate the recording hasn't been 
corrupted since it was stored, but it does nothing at all to verify the 
claims made in that recording, and is simply the wrong tool for the job 
if that's what you're trying to do.

Back on btrfs, if we were checksumming metadata and that metadata was 
faulty due to some now fixed bug, verifying the checksum simply verifies 
that the still-faulty metadata hasn't changed from when we stored it, not 
that the metadata isn't faulty in the first place.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman


      parent reply	other threads:[~2014-05-11  3:09 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-05-10 23:57 3.15-rc5 btrfs send/receive corruption errors? Does scrub Marc MERLIN
2014-05-11  1:59 ` David Brown
2014-05-11  3:09 ` Duncan [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='pan$ca817$195609f1$cf655dea$2b05cd43@cox.net' \
    --to=1i5t5.duncan@cox.net \
    --cc=linux-btrfs@vger.kernel.org \
    /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;
as well as URLs for NNTP newsgroup(s).