Linux-BTRFS Archive on lore.kernel.org
 help / Atom feed
* 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, back to index

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

Linux-BTRFS Archive on lore.kernel.org

Archives are clonable: git clone --mirror https://lore.kernel.org/linux-btrfs/0 linux-btrfs/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 linux-btrfs linux-btrfs/ https://lore.kernel.org/linux-btrfs \
		linux-btrfs@vger.kernel.org linux-btrfs@archiver.kernel.org
	public-inbox-index linux-btrfs


Newsgroup available over NNTP:
	nntp://nntp.lore.kernel.org/org.kernel.vger.linux-btrfs


AGPL code for this site: git clone https://public-inbox.org/ public-inbox