From: Duncan <1i5t5.duncan@cox.net>
To: linux-btrfs@vger.kernel.org
Subject: Re: Scrub on btrfs single device only to detect errors, not correct them?
Date: Mon, 7 Dec 2015 03:48:48 +0000 (UTC) [thread overview]
Message-ID: <pan$519f9$af10e2cb$f1ea2d14$435d0b5a@cox.net> (raw)
In-Reply-To: CAJCQCtQX5Ov6YKZ=SdxaGSPaGa0sEFF6gz89WsDm9qegmykGkA@mail.gmail.com
Chris Murphy posted on Sun, 06 Dec 2015 13:42:57 -0700 as excerpted:
> On Sun, Dec 6, 2015 at 12:15 PM, Jon Panozzo <jonp@lime-technology.com>
> wrote:
>> Just to confirm, is the sole purpose of supporting scrub on single
>> btrfs devices to detect errors, but not to correct them?
>
> If that single device metadata profile is DUP, then it will correct
> those. If there is only one copy of anything, then it just reports.
> Scrub works on all data, but a passive scrub happens anytime something
> is read.
... And more to the point, expanding on that, on a single device btrfs,
data is single mode by default, so scrub for it (as opposed to metadata)
is error-detect-only as mentioned.
However, while the default mode separates data and metadata, and in that
mode, historically (there's a patch to change this, adding the missing
option) data was single-only, mixed-bg mode (the mkfs.btrfs --mixed
option) puts data and metadata both in the same shared block-group type,
which can then be either dup or single mode.
Obviously duplicating data as well as metadata means you can only store
half as much data, since it's all stored twice, but that will let scrub
correct errors in cases where only one of the two copies doesn't verify
checksum, but the other one does.
And as mentioned above, there's a patch in process now, that will remove
the single-device restriction of data (as opposed to metadata) to single
mode, allowing the choice of dup mode for data as well as metadata.
Also, in addition to the mixed-mode workaround to get dup data, it's
possible, altho rather inefficient in performance terms, to partition a
physical device such that two equal sized partitions are made available
as logical devices, and then mkfs.btrf -d raid1 -m raid1 the two logical
devices into a single btrfs, raid1 for both data and metadata, so btrfs
creates two copies that way, again letting scrub correct errors when only
one of the two fails to verify against checksum.
--
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
next prev parent reply other threads:[~2015-12-07 3:48 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-12-06 19:15 Scrub on btrfs single device only to detect errors, not correct them? Jon Panozzo
2015-12-06 20:42 ` Chris Murphy
2015-12-07 3:48 ` Duncan [this message]
2015-12-07 14:43 ` Jon Panozzo
2015-12-08 13:38 ` Duncan
2015-12-07 14:47 ` Jon Panozzo
2015-12-07 15:01 ` Austin S Hemmelgarn
2015-12-07 15:12 ` Jon Panozzo
2015-12-07 15:39 ` Austin S Hemmelgarn
2015-12-08 14:15 ` Duncan
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$519f9$af10e2cb$f1ea2d14$435d0b5a@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 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.