From: Duncan <1i5t5.duncan@cox.net>
To: linux-btrfs@vger.kernel.org
Subject: Re: evidence of persistent state, despite device disconnects
Date: Sat, 9 Jan 2016 10:55:23 +0000 (UTC) [thread overview]
Message-ID: <pan$84a33$9b12297$c9fad6dd$fe3dbd43@cox.net> (raw)
In-Reply-To: CAJCQCtRkDrUhiCsgO5Wm=1OhpbtxaR58SLLg5JxZvYQE_nSTUQ@mail.gmail.com
Chris Murphy posted on Tue, 05 Jan 2016 14:47:52 -0700 as excerpted:
> On Tue, Jan 5, 2016 at 7:50 AM, Duncan <1i5t5.duncan@cox.net> wrote:
>
>
>> 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.
>
> Clearly I will have to retest.
>
> But even as rw,degraded, it doesn't matter, that'd still be a huge bug.
> There's no possible way you'll convince me this is a user
> misunderstanding. No where is this documented.
>
> I made the fs using mfks.btrfs -draid1 -mraid1. There is no way the fs,
> under any circumstance, legitimately creates and uses any other profile
> for any chunk type, ever. Let alone silently.
If you're mounting degraded,rw, and you're down to a single device on a
raid1, then once the existing chunks fill up, it /has/ to create single
chunks, because it can't create them raid1 as there's not enough devices
(a minimum of two devices are required to create raid1 chunks, since two
copies are required and they can't be on the same device).
And by mounting degraded,rw you've given it permission to create those
single mode chunks if it has to, so it's not "silent", as you've
explicitly mounted it degraded,rw, and single is what raid1 degrades to
when there's only one device.
And with automatic empty-chunk deletion, existing chunks can fill up
pretty fast...
Further, NOT letting it write single chunks when an otherwise raid1 btrfs
is mounted in degraded,rw mode, would very possibly prevent you from
repairing the filesystem with a btrfs replace or btrfs device add and
delete. And we've been there, done that, except slightly differently,
with the can only mount degraded,rw until a single mode chunk is written,
after which you can only mount degraded,ro, and then can't repair, which
is the problem that the per-chunk check patches, vs. the old filesystem-
scope check, were designed to eliminate.
But as I said, if it's creating single chunks when you did /not/ have it
mounted degraded, then you indeed have found a bug, and figuring out how
to replicate it so it can be properly traced and fixed is where we're
left, as I can't see how anyone would find that not 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-09 10:55 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
2016-01-05 21:47 ` Chris Murphy
2016-01-09 10:55 ` Duncan [this message]
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$84a33$9b12297$c9fad6dd$fe3dbd43@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).