Re: btrfs progs always assume devid 1?

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

On 2018-12-05 14:50, Roman Mamedov wrote:
> Hello,
> 
> To migrate my FS to a different physical disk, I have added a new empty device
> to the FS, then ran the remove operation on the original one.
> 
> Now my FS has only devid 2:
> 
> Label: 'p1'  uuid: d886c190-b383-45ba-9272-9f00c6a10c50
> 	Total devices 1 FS bytes used 36.63GiB
> 	devid    2 size 50.00GiB used 45.06GiB path /dev/mapper/vg-p1
> 
> And all the operations of btrfs-progs now fail to work in their default
> invocation, such as:
> 
> # btrfs fi resize max .
> Resize '.' of 'max'
> ERROR: unable to resize '.': No such device
> 
> [768813.414821] BTRFS info (device dm-5): resizer unable to find device 1
> 
> Of course this works:
> 
> # btrfs fi resize 2:max .
> Resize '.' of '2:max'
> 
> But this is inconvenient and seems to be a rather simple oversight. If what I
> got is normal (the device staying as ID 2 after such operation), then count
> that as a suggestion that btrfs-progs should use the first existing devid,
> rather than always looking for hard-coded devid 1.
> 

I've been meaning to try and write up a patch to special-case this for a 
while now, but have not gotten around to it yet.

FWIW, this is one of multiple reasons that it's highly recommended to 
use `btrfs replace` instead of adding a new device and deleting the old 
one when replacing a device.  Other benefits include:

* It doesn't have to run in the foreground (and doesn't by default).
* It usually takes less time.
* Replace operations can be queried while running to get a nice 
indication of the completion percentage.

The only disadvantage is that the new device has to be at least as large 
as the old one (though you can get around this to a limited degree by 
shrinking the old device), and it needs the old and new device to be 
plugged in at the same time (add/delete doesn't, if you flip the order 
of the add and delete commands).