All of lore.kernel.org
 help / color / mirror / Atom feed
From: Zack Coffey <tech42.clickwir@gmail.com>
To: Robert White <rwhite@pobox.com>, linux-btrfs@vger.kernel.org
Subject: Re: RAID1 fails to recover chunk tree
Date: Fri, 31 Oct 2014 08:15:25 -0400	[thread overview]
Message-ID: <54537D5D.3020506@gmail.com> (raw)
In-Reply-To: <545349C4.2020104@pobox.com>

Sadly I think I understand now.

So by adding the second drive, BTRFS saw it as an extension of data (ala 
JBOD-ish?). Even though I thought I was only adding RAID1 for metadata, 
was also adding to the data storage.

I assume that even though chunk-recover reports healthy chunks, there's 
little to no way to actually get them?


On 10/31/2014 4:35 AM, Robert White wrote:
> 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.


  reply	other threads:[~2014-10-31 12:15 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
2014-10-31 12:15         ` Zack Coffey [this message]
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=54537D5D.3020506@gmail.com \
    --to=tech42.clickwir@gmail.com \
    --cc=linux-btrfs@vger.kernel.org \
    --cc=rwhite@pobox.com \
    --cc=zcoffey@mytech42.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 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.