From: Duncan <1i5t5.duncan@cox.net>
To: linux-btrfs@vger.kernel.org
Subject: Re: evidence of persistent state, despite device disconnects
Date: Tue, 5 Jan 2016 14:50:23 +0000 (UTC) [thread overview]
Message-ID: <pan$4b55a$cfffcc6c$c8faaa76$1740646a@cox.net> (raw)
In-Reply-To: CAJCQCtSCvzoOdqFx9dB9sbT-dR0XsQVzWwVcK3zBnwC17+ZV_Q@mail.gmail.com
Chris Murphy posted on Sun, 03 Jan 2016 14:33:40 -0700 as excerpted:
> kernel-4.4.0-0.rc6.git0.1.fc24.x86_64 btrfs-progs 4.3.1
>
> There was some copy pasting, hence /mnt/brick vs /mnt/brick2 confusion,
> but the volume was always cleanly mounted and umounted.
>
> The biggest problem I have with all of this is the completely silent
> addition of single chunks. That made the volume, in effect, no longer
> completely raid1. No other details matter, except to try and reproduce
> the problem, and find its source so it can be fixed. It is a bug,
> because it's definitely not sane or expected behavior at all.
If there's no way you mounted it degraded,rw at any point, I agree,
single mode chunks are unexpected on a raid1 for both data and metadata,
and it's a bug -- possibly actually related to that new code that allows
degraded,rw recovery via per-chunk checks.
If however you mounted it degraded,rw at some point, then I'd say the bug
is in wetware, as in that case, based on my understanding, it's working
as intended. I was inclined to believe that was what happened based on
the obviously partial sequence in the earlier post, but if you say you
didn't... then it's all down to duplication and finding why it's suddenly
reverting to single mode on non-degraded mounts, which indeed /is/ a bug.
--
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:[~2016-01-05 14:50 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-01-02 19:22 evidence of persistent state, despite device disconnects Chris Murphy
2016-01-03 13:48 ` Duncan
2016-01-03 21:33 ` Chris Murphy
2016-01-05 14:50 ` Duncan [this message]
2016-01-05 21:47 ` Chris Murphy
2016-01-09 10:55 ` Duncan
2016-01-09 22:29 ` Chris Murphy
2016-01-10 5:34 ` Duncan
2016-01-10 16:54 ` Goffredo Baroncelli
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$4b55a$cfffcc6c$c8faaa76$1740646a@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).