All of lore.kernel.org
 help / color / mirror / Atom feed
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


  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.