From: Duncan <1i5t5.duncan@cox.net>
To: linux-btrfs@vger.kernel.org
Subject: Re: Replacing drives with larger ones in a 4 drive raid1
Date: Mon, 13 Jun 2016 03:54:08 +0000 (UTC) [thread overview]
Message-ID: <pan$68dc6$cfb2f3f9$47775110$b24d1225@cox.net> (raw)
In-Reply-To: CAPmG0jYTd0a3NfzAXSGCBkMxZNQQ0pE+U_bmd3ks4x0OAWL6Rw@mail.gmail.com
Henk Slager posted on Sun, 12 Jun 2016 21:03:22 +0200 as excerpted:
> But now that you anyhow have all data on 3x 6TB drives, you could save
> balancing time by just doing btrfs-replace 6TB to 8TB 3x and then for
> the 4th 8TB just add it and let btrfs do the spreading/balancing over
> time by itself.
That's what I'd suggest. You have all the data on three of the 6 TB
drives now. Just replace one at a time to 8 TB drives. Then add the 4th
8 TB drive, and then at your option do a final balance at that point, or
simply let the normal activity take care of it.
Altho if you're doing mostly add, little delete, without a balance you
may run out of space prematurely, since raid1 requires two drives with
unallocated space on them to allocate a new chunk (one copy on each of
the two), and you'll only have ~2 TB free on each of the three, which
would be used up with ~2 TB still left free on the last added drive...
So at least a partial balance after adding that 4th 8 TB in is probably a
good idea. You can leave that last drive with a couple extra free TB
compared to the others and cancel the balance at that point, and new
allocations should take it from there, but unless you're going to be
deleting several TB of stuff as you add, at least doing a few TB worth of
balance to the new drive to start the process should result in a pretty
even spread as it fills up the rest of the way.
--
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:[~2016-06-13 3:54 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-06-08 18:55 Replacing drives with larger ones in a 4 drive raid1 boli
2016-06-09 15:20 ` Duncan
2016-06-09 17:30 ` bOli
2016-06-10 18:56 ` Jukka Larja
2016-06-11 13:13 ` boli
2016-06-12 10:35 ` boli
2016-06-12 15:24 ` Henk Slager
2016-06-12 17:03 ` boli
2016-06-12 19:03 ` Henk Slager
2016-06-13 3:54 ` Duncan [this message]
2016-06-13 12:24 ` Austin S. Hemmelgarn
2016-06-14 19:28 ` boli
2016-06-15 3:19 ` Duncan
2016-06-16 0:09 ` boli
2016-06-16 18:18 ` boli
2016-06-17 6:25 ` Duncan
2016-06-19 17:38 ` boli
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$68dc6$cfb2f3f9$47775110$b24d1225@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 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.