From: Robert White <rwhite@pobox.com>
To: Zack Coffey <tech42.clickwir@gmail.com>, linux-btrfs@vger.kernel.org
Subject: Re: RAID1 fails to recover chunk tree
Date: Fri, 31 Oct 2014 01:35:16 -0700 [thread overview]
Message-ID: <545349C4.2020104@pobox.com> (raw)
In-Reply-To: <54523D86.5040906@gmail.com>
On 10/30/2014 06:30 AM, Zack Coffey wrote:
> Rob, That second drive was immediately put to use elsewhere. I figured
> having only the metadata on that drive, it wouldn't matter. The data
> stayed single and wasn't part of the second drive, only the metadata
> was. I must not be capable of understanding why that wouldn't work.
>
> I thought all I was doing was removing a duplication of metadata and the
> worst I would see is a message complaining about a drive missing. Never
> thought the data or access to it could be compromised in what seemed to
> be a simple situation.
>
> Anand, I get the same output with mount -o recovery,ro.
Your data is gone if your other drive is gone.
Single doesn't mean what you think it means. Single means "one single
copy of your data", but it has _nothing_ to do with "one single drive".
That would mean that after a "btrfs device add" the default would be to
never, ever, use that added drive.
So RAID0 means "striped", so there are chunks, then chunk=0 is on
drive=0 at offset zero. Chunk=1 is on drive=1 at offset zero. (where
there are N drives.) Chunk=N is on drive=N at offset zero. Chunk=N+1 is
on drive=0 at offset Chunk_Size+1. And so on.
Concatenation is that drive=N follows drive=N-1 at offset
sum(sizeofeach(all drives less than N)). So Byte=0 is on drive=0 at
offset0; and Byte=(sizeof drive0) is on drive=1 at byte=0.
The RAID standard never addressed bulk concatenation, so there is no
"raid-number" for the one whole drive after another. BTRFS uses
"single", others use other words.
So if you had a 100G drive, and you added a second 100G drive, you'd
have a logically 200G drive, where the first 100G is on drive one, and
the second is on drive two.
You've basically obliterated the second half of the filesystem storage
when you physically removed the drive without semantically removing it
first. Might as well have erased it with a magnet, and all the data with
it. Worse still, if you did any sort of balance or defrag you likely
moved huge numbers of "the _single_ copy of your data" clusters onto
that other device.
So the layout option isn't about limiting storage, that wouldn't make
sense, that's what device add/delete is about. Its about how the data is
laid out across all the drives.
All those unreachable addresses are on that now-defunct drive. No mount
option will ever get you that data back.
next prev parent reply other threads:[~2014-10-31 8:35 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-10-28 20:32 RAID1 fails to recover chunk tree Zack Coffey
2014-10-29 3:55 ` Anand Jain
2014-10-29 19:32 ` Zack Coffey
2014-10-30 3:33 ` Anand Jain
2014-10-29 22:26 ` Robert White
2014-10-29 23:07 ` Robert White
2014-10-30 13:30 ` Zack Coffey
2014-10-30 15:23 ` Zygo Blaxell
2014-10-30 18:04 ` Chris Murphy
2014-10-31 1:27 ` Duncan
2014-10-31 2:09 ` Chris Murphy
2014-11-02 4:26 ` Robert White
2014-11-02 8:48 ` Roman Mamedov
2014-11-02 11:08 ` Robert White
2014-11-03 6:52 ` Duncan
2014-11-03 8:00 ` Duncan
2014-10-31 8:35 ` Robert White [this message]
2014-10-31 12:15 ` Zack Coffey
2014-11-02 4:19 ` Robert White
-- strict thread matches above, loose matches on Subject: below --
2014-10-28 20:18 Zack Coffey
2014-10-27 19:01 Zack Coffey
2014-10-15 21:09 Zack Coffey
2014-10-15 15:42 Zack Coffey
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=545349C4.2020104@pobox.com \
--to=rwhite@pobox.com \
--cc=linux-btrfs@vger.kernel.org \
--cc=tech42.clickwir@gmail.com \
/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