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
next prev parent 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