Hi Igor,
The immediate answer is to use "ceph-volume lvm zap" on the db LV after
running the migrate. But for the longer term I think the "lvm zap" should
be included in the "lvm migrate" process.
I.e. this works to migrate a separate wal/db to the block device:
#
# WARNING! DO NOT ZAP AFTER
Hi Igor,
On Wed, Nov 15, 2023 at 12:30:57PM +0300, Igor Fedotov wrote:
Hi Chris,
haven't checked you actions thoroughly but migration to be done on a
down OSD which is apparently not the case here.
May be that's a culprit and we/you somehow missed the relevant error
during the migration pro
Oh right, I responded from my mobile phone and missed the examples.
Thanks for the clarification!
OP did stop the OSD according to his output:
$ cephadm unit --fsid ${fsid} --name osd.${osdid} stop
But there might have been an error anyway, I guess.
Zitat von Igor Fedotov :
Hi Eugen,
th
Hi Chris,
haven't checked you actions thoroughly but migration to be done on a
down OSD which is apparently not the case here.
May be that's a culprit and we/you somehow missed the relevant error
during the migration process?
Thanks,
Igor
On 11/15/2023 5:33 AM, Chris Dunlop wrote:
Hi,
Hi Eugen,
this scenario is supported, see the last example on the relevant doc page:
Moves BlueFS data from main, DB and WAL devices to main device, WAL and
DB are removed:
ceph-volume lvm migrate --osd-id 1 --osd-fsid--from db wal
--target vgname/data
Thanks,
Igor
On 11/15/2
Hi,
AFAIU, you can’t migrate back to the slow device. It’s either
migrating from the slow device to a fast device or remove between fast
devices. I’m not aware that your scenario was considered in that tool.
The docs don’t specifically say that, but they also don’t mention
going back to s
