* btrfs progs always assume devid 1?
@ 2018-12-05 19:50 Roman Mamedov
2018-12-05 20:10 ` Austin S. Hemmelgarn
0 siblings, 1 reply; 2+ messages in thread
From: Roman Mamedov @ 2018-12-05 19:50 UTC (permalink / raw)
To: linux-btrfs
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.
--
With respect,
Roman
^ permalink raw reply [flat|nested] 2+ messages in thread
* Re: btrfs progs always assume devid 1?
2018-12-05 19:50 btrfs progs always assume devid 1? Roman Mamedov
@ 2018-12-05 20:10 ` Austin S. Hemmelgarn
0 siblings, 0 replies; 2+ messages in thread
From: Austin S. Hemmelgarn @ 2018-12-05 20:10 UTC (permalink / raw)
To: Roman Mamedov, linux-btrfs
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).
^ permalink raw reply [flat|nested] 2+ messages in thread
end of thread, other threads:[~2018-12-05 20:10 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2018-12-05 19:50 btrfs progs always assume devid 1? Roman Mamedov
2018-12-05 20:10 ` Austin S. Hemmelgarn
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.