From: Hugo Mills <hugo@carfax.org.uk>
To: "Michael Kjörling" <michael@kjorling.se>
Cc: linux-btrfs@vger.kernel.org
Subject: Re: How does btrfs behave on checksum mismatch?
Date: Sat, 27 Oct 2012 23:02:15 +0100 [thread overview]
Message-ID: <20121027220215.GA5042@carfax.org.uk> (raw)
In-Reply-To: <20121027215645.GU2381@yeono.kjorling.se>
[-- Attachment #1: Type: text/plain, Size: 2093 bytes --]
On Sat, Oct 27, 2012 at 09:56:45PM +0000, Michael Kjörling wrote:
> I came across the tidbit that ZFS has a contract guarantee that the
> data read back will either be correct (the checksum computed over the
> data read from the disk matches the checksum stored on disk), or you
> get an I/O error. Obviously, this greatly reduces the probability that
> the data is invalid. (Particularly when taken in combination with the
> disk firmware's own ECC and checksumming.)
>
> With the default options, does btrfs make any similar guarantees? If
> not, then are there any options to force it to make such guarantees?
It does indeed do the same thing: if the checksum doesn't match the
block, then the alternative block is read (if one exists, e.g. RAID-1,
RAID-10). If that does not exist, or also has a checksum failure, then
EIO is returned.
Hugo.
> I'm interested in this both from a specification and an implementation
> point of view.
>
> The last thing anyone wants is probably undetected bit rot, and with
> today's large drives, even with the quite low bit rot numbers it can
> be a real concern. If even the act of simply successfully reading a
> file guarantees, to the extent of the checksumming algorithm's ability
> to detect changes, that the data read is the same as was once written,
> that would be a major selling point for btrfs for me personally.
>
> The closest I was able to find was that btrfs uses crc32c currently
> for data and metadata checksumming and that this can be turned off if
> so desired (using the "nodatasum" mount option), but nothing about
> what the file system code does or is supposed to do in the face of a
> checksum mismatch.
--
=== Hugo Mills: hugo@... carfax.org.uk | darksatanic.net | lug.org.uk ===
PGP key: 515C238D from wwwkeys.eu.pgp.net or http://www.carfax.org.uk
--- It used to take a lot of talent and a certain type of ---
upbringing to be perfectly polite and have filthy manners
at the same time. Now all it needs is a computer.
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 828 bytes --]
next prev parent reply other threads:[~2012-10-27 22:02 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-10-27 21:56 How does btrfs behave on checksum mismatch? Michael Kjörling
2012-10-27 22:02 ` Hugo Mills [this message]
2012-10-27 22:09 ` Michael Kjörling
2012-10-28 12:23 ` Ronnie Collinson
2012-10-28 13:23 ` Martin Steigerwald
2012-10-28 13:26 ` Hugo Mills
2012-10-28 13:36 ` Martin Steigerwald
2012-10-28 13:39 ` Hugo Mills
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=20121027220215.GA5042@carfax.org.uk \
--to=hugo@carfax.org.uk \
--cc=linux-btrfs@vger.kernel.org \
--cc=michael@kjorling.se \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.