* Drive Replacement
@ 2016-10-21 22:03 Gareth Pye
2016-10-21 22:07 ` Hugo Mills
0 siblings, 1 reply; 4+ messages in thread
From: Gareth Pye @ 2016-10-21 22:03 UTC (permalink / raw)
To: linux-btrfs
I've got a BTRFS array that is of mixed size disks:
2x750G
3x1.5T
3x3T
And it's getting fuller than I'd like. The problem is that adding
disks is harder than one would like as the computer only has 8 sata
ports. Is it viable to do the following to upgrade one of the disks?
A) Take array offline
B) DD the contents of one of the 750G drives to a new 3T drive
C) Remove the 750G from the system
D) btrfs scan
E) Mount array
F) Run a balance
I know that not physically removing the old copy of the drive will
cause massive issues, but if I do that everything should be fine
right?
--
Gareth Pye - chatterofjudges.mtgmelb.com
Level 2 MTG Judge, Melbourne, Australia
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Drive Replacement
2016-10-21 22:03 Drive Replacement Gareth Pye
@ 2016-10-21 22:07 ` Hugo Mills
2016-10-21 22:13 ` Peter Becker
0 siblings, 1 reply; 4+ messages in thread
From: Hugo Mills @ 2016-10-21 22:07 UTC (permalink / raw)
To: Gareth Pye; +Cc: linux-btrfs
[-- Attachment #1: Type: text/plain, Size: 1102 bytes --]
On Sat, Oct 22, 2016 at 09:03:16AM +1100, Gareth Pye wrote:
> I've got a BTRFS array that is of mixed size disks:
> 2x750G
> 3x1.5T
> 3x3T
> And it's getting fuller than I'd like. The problem is that adding
> disks is harder than one would like as the computer only has 8 sata
> ports. Is it viable to do the following to upgrade one of the disks?
>
> A) Take array offline
> B) DD the contents of one of the 750G drives to a new 3T drive
> C) Remove the 750G from the system
> D) btrfs scan
> E) Mount array
> F) Run a balance
>
> I know that not physically removing the old copy of the drive will
> cause massive issues, but if I do that everything should be fine
> right?
Yes. The one thing missing here is running
# btrfs dev resize <devid>:max /mountpoint
on the new device between steps E and F to allow the FS to use the
full amount of the device. Otherwise, it'll still be the same size as
the original.
Hugo.
--
Hugo Mills | Great films about cricket: Batsman Begins
hugo@... carfax.org.uk | starring Christian Bail
http://carfax.org.uk/ |
PGP: E2AB1DE4 |
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Drive Replacement
2016-10-21 22:07 ` Hugo Mills
@ 2016-10-21 22:13 ` Peter Becker
2016-10-24 11:47 ` Austin S. Hemmelgarn
0 siblings, 1 reply; 4+ messages in thread
From: Peter Becker @ 2016-10-21 22:13 UTC (permalink / raw)
To: Hugo Mills, Gareth Pye, linux-btrfs
if you have >750 GB free you can simply remove one of the drives.
btrfs device delete /dev/sd[x] /mnt
#power off, replace device
btrfs device add /dev/sd[y] /mnt
if not you can use an USB-SATA adapter or an eSata-Port and make the following:
btrfs device add /dev/sd[y] /mnt
btrfs device delete /dev/sd[x] /mnt
#power off, replace device
i avoid "btrfs device replace" because it's slower then add+delete
and don't forget to update fstab !
2016-10-22 0:07 GMT+02:00 Hugo Mills <hugo@carfax.org.uk>:
> On Sat, Oct 22, 2016 at 09:03:16AM +1100, Gareth Pye wrote:
>> I've got a BTRFS array that is of mixed size disks:
>> 2x750G
>> 3x1.5T
>> 3x3T
>> And it's getting fuller than I'd like. The problem is that adding
>> disks is harder than one would like as the computer only has 8 sata
>> ports. Is it viable to do the following to upgrade one of the disks?
>>
>> A) Take array offline
>> B) DD the contents of one of the 750G drives to a new 3T drive
>> C) Remove the 750G from the system
>> D) btrfs scan
>> E) Mount array
>> F) Run a balance
>>
>> I know that not physically removing the old copy of the drive will
>> cause massive issues, but if I do that everything should be fine
>> right?
>
> Yes. The one thing missing here is running
>
> # btrfs dev resize <devid>:max /mountpoint
>
> on the new device between steps E and F to allow the FS to use the
> full amount of the device. Otherwise, it'll still be the same size as
> the original.
>
> Hugo.
>
> --
> Hugo Mills | Great films about cricket: Batsman Begins
> hugo@... carfax.org.uk | starring Christian Bail
> http://carfax.org.uk/ |
> PGP: E2AB1DE4 |
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Drive Replacement
2016-10-21 22:13 ` Peter Becker
@ 2016-10-24 11:47 ` Austin S. Hemmelgarn
0 siblings, 0 replies; 4+ messages in thread
From: Austin S. Hemmelgarn @ 2016-10-24 11:47 UTC (permalink / raw)
To: Peter Becker, Hugo Mills, Gareth Pye, linux-btrfs
On 2016-10-21 18:13, Peter Becker wrote:
> if you have >750 GB free you can simply remove one of the drives.
>
> btrfs device delete /dev/sd[x] /mnt
> #power off, replace device
> btrfs device add /dev/sd[y] /mnt
Make sure to balance afterwards if you do this, the new disk will be
pretty much unused until you do.
>
> if not you can use an USB-SATA adapter or an eSata-Port and make the following:
>
> btrfs device add /dev/sd[y] /mnt
> btrfs device delete /dev/sd[x] /mnt
> #power off, replace device
I will comment that eSATA is vastly preferred to USB in this case (even
a USB3.0 UAS device) as it is generally significantly more reliable
(even if you are just using a eSATA to SATA cable and a power adapter
for the drive).
>
> i avoid "btrfs device replace" because it's slower then add+delete
In my experience, this is only true if you add then delete (delete then
add then re-balance will move a lot of data twice), and even then only
if the device is more than about half full. Device replace also has a
couple of specific advantages:
* It lets you get an exact percentage completion, unlike add+delete.
This is only updated every few seconds, and doesn't show an estimate of
time remaining, but is still better than nothing.
* Device ID's remain the same. This can be an advantage or a
disadvantage, but it's usually a good thing in a case like this, because
the mapping between device number and device node (and therefore
specific disks) will remain constant, which makes tracking which
physical device is failing a bit easier if you have consistent device
enumeration for storage devices (which you almost certainly do if you're
using SATA).
* It doesn't write any data on any other device except for superblocks
and the basic metadata that describes the device layout. This is
important because it means that it's safer for data that isn't on the
device being replaced, and it has less impact on other operations when
doing a live replacement.
>
> and don't forget to update fstab !
Assuming that he doesn't change which SATA ports the devices are
connected to, he shouldn't have to change anything in /etc/fstab. Mount
by UUID or LABEL will just work regardless, and mount by device node
will continue to work as long as the same device nodes are used (which
will be the case if he doesn't change anything else in the storage stack).
>
> 2016-10-22 0:07 GMT+02:00 Hugo Mills <hugo@carfax.org.uk>:
>> On Sat, Oct 22, 2016 at 09:03:16AM +1100, Gareth Pye wrote:
>>> I've got a BTRFS array that is of mixed size disks:
>>> 2x750G
>>> 3x1.5T
>>> 3x3T
>>> And it's getting fuller than I'd like. The problem is that adding
>>> disks is harder than one would like as the computer only has 8 sata
>>> ports. Is it viable to do the following to upgrade one of the disks?
>>>
>>> A) Take array offline
>>> B) DD the contents of one of the 750G drives to a new 3T drive
>>> C) Remove the 750G from the system
>>> D) btrfs scan
>>> E) Mount array
>>> F) Run a balance
>>>
>>> I know that not physically removing the old copy of the drive will
>>> cause massive issues, but if I do that everything should be fine
>>> right?
>>
>> Yes. The one thing missing here is running
>>
>> # btrfs dev resize <devid>:max /mountpoint
>>
>> on the new device between steps E and F to allow the FS to use the
>> full amount of the device. Otherwise, it'll still be the same size as
>> the original.
>>
>> Hugo.
>>
>> --
>> Hugo Mills | Great films about cricket: Batsman Begins
>> hugo@... carfax.org.uk | starring Christian Bail
>> http://carfax.org.uk/ |
>> PGP: E2AB1DE4 |
> --
> To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2016-10-24 11:47 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2016-10-21 22:03 Drive Replacement Gareth Pye
2016-10-21 22:07 ` Hugo Mills
2016-10-21 22:13 ` Peter Becker
2016-10-24 11:47 ` Austin S. Hemmelgarn
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).