public inbox for linux-btrfs@vger.kernel.org
 help / color / mirror / Atom feed
From: Hugo Mills <hugo@carfax.org.uk>
To: Arnaud Kapp <kapp.arno@gmail.com>
Cc: linux-btrfs <linux-btrfs@vger.kernel.org>
Subject: Re: Replacing a drive from a RAID 1 array
Date: Tue, 16 Jun 2015 16:58:32 +0000	[thread overview]
Message-ID: <20150616165832.GN9850@carfax.org.uk> (raw)
In-Reply-To: <CAOQP4cG2344VZYT8eZ4=MJzi_KsdzH7pxFJ+ZpOTXtdDOrXRyQ@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 1923 bytes --]

On Tue, Jun 16, 2015 at 06:43:23PM +0200, Arnaud Kapp wrote:
> Hello,
> 
> Consider the following situation: I have a RAID 1 array with 4 drives.
> I want to replace one the drive by a new one, with greater capacity.
> 
> However, let's say I only have 4 HDD slots so I cannot plug the new
> drive, add it to the array then remove the other one.
> If there a *safe* way to change drives in this situation? I'd bet that
> booting with 3drives, adding the new one then removing the old, non
> connected one would work. However, is there something that could go
> wrong in this situation?

   The main thing that could go wrong with that is a disk failure. If
you have the SATA ports available, I'd consider operating the machine
with the case open and one of the drives bare and resting on something
stable and insulating for the time it takes to do a "btrfs replace"
operation.

   If that's not an option, then a good-quality external USB case with
a short cable directly attached to one of the USB ports on the
motherboard would be a reasonable solution (with the proviso that some
USB connections are just plain unstable and throw errors, which can
cause problems with the filesystem code, typically requiring a reboot,
and a restart of the process).

   You might also consider using either NBD or iSCSI to present one of
the disks (I'd probably use the outgoing one) over the network from
another machine with more slots in it, but that's going to end up with
horrible performance during the migration.

   In my big disk array at home, I have two 4-slot enclosures, and I
leave one of them empty specifically for this reason. It's a less
attractive proposition with only 4 slots in total, though.

   Hugo.

-- 
Hugo Mills             | "What are we going to do tonight?"
hugo@... carfax.org.uk | "The same thing we do every night, Pinky. Try to
http://carfax.org.uk/  | take over the world!"
PGP: E2AB1DE4          |

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

  reply	other threads:[~2015-06-16 16:58 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-06-16 16:43 Replacing a drive from a RAID 1 array Arnaud Kapp
2015-06-16 16:58 ` Hugo Mills [this message]
2015-06-16 21:04   ` Chris Murphy
2015-06-17  0:51   ` Duncan
2015-06-17 11:30   ` Austin S Hemmelgarn

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=20150616165832.GN9850@carfax.org.uk \
    --to=hugo@carfax.org.uk \
    --cc=kapp.arno@gmail.com \
    --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