Linux Btrfs filesystem development
 help / color / mirror / Atom feed
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: Wed, 29 Oct 2014 15:26:35 -0700	[thread overview]
Message-ID: <5451699B.4020507@pobox.com> (raw)
In-Reply-To: <544FFD52.6010604@gmail.com>

On 10/28/2014 01:32 PM, Zack Coffey wrote:
> Made a RAID1 with another drive of just the metadata. Was in
> that state for less than 12 hours-ish, removed the second drive and
> now cannot get to any data on the original drive. Data remained single
> while only metadata was RAID1.

I don't know all the details but I would _never_ suspect the action you 
described to _not_ hose up the file system.

The "single" mode is not "restrict to one drive" its concatenation, as 
in treat the entire space as if it were a single drive.

In that twelve hour window data migrated. I _think_ directories may 
count as data in this sense. If a key element (say the root directory) 
migrated onto the disk you eventually removed then there is no root 
directory to read. And if not root, then any secondary directory you choose.

So sure your checksum trees and your extent maps were all duplicated in 
the mirror, but your actual data -- you know all those files that were 
copied on write -- may well be only on that second drive you pulled out.

RAID metadata, and non RAID1 data, would not safely allow for failure 
(or removal) of one drive.

I'm not sure what you expected to happen but what you did is full of fail.

You need to put the second drive back in and then coerce all the data 
back to the first drive. "btrfs device delete" is what you want. You 
_may_ need to switch the metadata back to "single" before the delete.

--Rob.

  parent reply	other threads:[~2014-10-29 22:26 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 [this message]
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
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=5451699B.4020507@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