Linux Btrfs filesystem development
 help / color / mirror / Atom feed
From: Duncan <1i5t5.duncan@cox.net>
To: linux-btrfs@vger.kernel.org
Subject: Re: RAID1 fails to recover chunk tree
Date: Fri, 31 Oct 2014 01:27:03 +0000 (UTC)	[thread overview]
Message-ID: <pan$2cd78$85acd913$95d42126$8a9a4137@cox.net> (raw)
In-Reply-To: 58060F93-3CB7-4575-9AF7-59DAF895CE7B@colorremedies.com

Chris Murphy posted on Thu, 30 Oct 2014 12:04:48 -0600 as excerpted:

>> 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.
> 
> single profile means all devices get btrfs chunks. If you do something
> like:
> 
> # mkfs.btfs /dev/sda
> 
> By default you get data profile = single, and metadata profile = DUP. If
> you then
> 
> # btrfs add /dev/sdb /mnt/btrfs # btrfs -mconvert=raid1  /mnt/btrfs
> 
> you now have a volume that is data = single and metadata = raid1. The 
way
> the allocator works is that it will first allocate 1GiB data chunks to 
the
> device with the most free space remaining, so if that's /dev/sdb it will
> allocate 1GiB data chunks there until free space is the same for both 
sda
> and sdb. And once they have equal space btrfs allocates 1GiB data chunks
> alternating sda and sdb.
> 
> Single profile doesn't mean only one device gets data chunks. Is that 
the
> misunderstanding?

Just what I was going to say.

Single profile means there's just one copy, and the normal chunk 
allocation algorithm allocates new chunks from the device with the most 
space left.  The freshly added device almost certainly had the most space 
left, so as soon as the existing data chunk was full, probably all new 
data chunks were allocated from the freshly added device.

Then you (OP) go and kill that device as far as btrfs is concerned, and 
all that new data written to it in single mode is ONLY on it because it 
was written in single mode, so now it has suddenly disappeared!

No WONDER that filesystem's having problems!

Even old files, due to copy on write, would have likely been partially or 
entirely moved to the new chunks on the new device if they were updated 
during the time the filesystem was mounted writable with the new device 
there.  And some desktop environments, for instance, have a habit of 
rewriting what might well be the exact same thing back to their config 
files, every time they shutdown, or sometimes as soon as they read it in 
at startup, as well.  So much of your desktop config may well have been 
on that second device, even if you didn't actively change any config 
during that time.

-- 
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


  reply	other threads:[~2014-10-31  1:27 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 [this message]
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='pan$2cd78$85acd913$95d42126$8a9a4137@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