From: Duncan <1i5t5.duncan@cox.net>
To: Hugo Mills <hugo@carfax.org.uk>
Cc: linux-btrfs@vger.kernel.org
Subject: Re: What is the vision for btrfs fs repair?
Date: Thu, 9 Oct 2014 05:42:31 -0700 [thread overview]
Message-ID: <20141009054231.7f28f7d5@ws> (raw)
In-Reply-To: <0zvr1p0162Q6ekd01zvtN0>
On Thu, 9 Oct 2014 12:55:50 +0100
Hugo Mills <hugo@carfax.org.uk> wrote:
> On Thu, Oct 09, 2014 at 11:53:23AM +0000, Duncan wrote:
> > Austin S Hemmelgarn posted on Thu, 09 Oct 2014 07:29:23 -0400 as
> > excerpted:
> >
> > > Also, you should be running btrfs scrub regularly to correct
> > > bit-rot and force remapping of blocks with read errors. While
> > > BTRFS technically handles both transparently on reads, it only
> > > corrects thing on disk when you do a scrub.
> >
> > AFAIK that isn't quite correct. Currently, the number of copies is
> > limited to two, meaning if one of the two is bad, there's a 50%
> > chance of btrfs reading the good one on first try.
>
> Scrub checks both copies, though. It's ordinary reads that don't.
While I believe I was clear in full context (see below), agreed. I was
talking about normal reads in the above, not scrub, as the full quote
should make clear. I guess I could have made it clearer in the
immediate context, however. Thanks.
> > Thus, while btrfs may randomly bump into a bad block and rewrite it
> > with the good copy, scrub is the only way to systematically detect
> > and (if there's a good copy) fix these checksum errors.
--
Duncan - No HTML messages please, as they are filtered as spam.
"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:[~2014-10-09 12:42 UTC|newest]
Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-10-08 19:11 What is the vision for btrfs fs repair? Eric Sandeen
2014-10-09 11:29 ` Austin S Hemmelgarn
2014-10-09 11:53 ` Duncan
2014-10-09 11:55 ` Hugo Mills
2014-10-09 12:07 ` Austin S Hemmelgarn
2014-10-09 12:12 ` Hugo Mills
2014-10-09 12:32 ` Austin S Hemmelgarn
[not found] ` <107Y1p00G0wm9Bl0107vjZ>
2014-10-09 12:34 ` Duncan
2014-10-09 13:18 ` Austin S Hemmelgarn
2014-10-09 13:49 ` Duncan
2014-10-09 15:44 ` Eric Sandeen
[not found] ` <0zvr1p0162Q6ekd01zvtN0>
2014-10-09 12:42 ` Duncan [this message]
2014-10-10 1:58 ` Chris Murphy
2014-10-10 3:20 ` Duncan
2014-10-10 10:53 ` Bob Marley
2014-10-10 10:59 ` Roman Mamedov
2014-10-10 11:12 ` Bob Marley
2014-10-10 15:18 ` cwillu
2014-10-10 14:37 ` Chris Murphy
2014-10-10 17:43 ` Bob Marley
2014-10-10 17:53 ` Bardur Arantsson
2014-10-10 19:35 ` Austin S Hemmelgarn
2014-10-10 22:05 ` Eric Sandeen
2014-10-13 11:26 ` Austin S Hemmelgarn
2014-10-12 10:14 ` Martin Steigerwald
2014-10-12 23:59 ` Duncan
2014-10-13 11:37 ` Austin S Hemmelgarn
2014-10-13 11:48 ` Rich Freeman
2014-10-11 7:29 ` Goffredo Baroncelli
2014-11-17 20:55 ` Phillip Susi
2014-10-12 10:06 ` Martin Steigerwald
2014-10-12 10:17 ` Martin Steigerwald
2014-10-13 21:09 ` Josef Bacik
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=20141009054231.7f28f7d5@ws \
--to=1i5t5.duncan@cox.net \
--cc=hugo@carfax.org.uk \
--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.