Re: Drive Replacement

["Austin S. Hemmelgarn" <ahferroin7@gmail.com>]

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
>