Hi Vojtech,
Thanks for looking it up.
It looks like the merging started in the background after all.
But here is the issue..
Merge initiates at 2022-01-04 17:40:31
2022-01-04.17:40:31 MERGELV
And I do get a return code of that it starting in background, as the next command is executed, that tries to mount the filesystem
2022-01-04.17:40:37 MOUNTFS
But, in the kernel log I can see these errors from mountfs, which I looping with a retry every 1s until it can get mounted
Jan 4 17:40:38 debian10 kernel: [42138.075811] XFS (dm-6): device supports 1024 byte sectors (not 512)
Jan 4 17:40:39 debian10 kernel: [42139.522164] XFS (dm-6): device supports 1024 byte sectors (not 512)
Jan 4 17:40:41 debian10 kernel: [42140.877383] XFS (dm-6): device supports 1024 byte sectors (not 512)
Jan 4 17:40:42 debian10 kernel: [42142.337237] XFS (dm-6): device supports 1024 byte sectors (not 512)
Jan 4 17:40:43 debian10 kernel: [42143.757615] XFS (dm-6): device supports 1024 byte sectors (not 512)
Jan 4 17:40:45 debian10 kernel: [42145.155576] XFS (dm-6): device supports 1024 byte sectors (not 512)
Jan 4 17:40:46 debian10 kernel: [42146.277236] XFS (dm-6): device supports 1024 byte sectors (not 512)
Jan 4 17:40:47 debian10 kernel: [42147.287412] XFS (dm-6): device supports 1024 byte sectors (not 512)
Jan 4 17:40:48 debian10 kernel: [42148.317816] XFS (dm-6): device supports 1024 byte sectors (not 512)
Jan 4 17:40:49 debian10 kernel: [42149.322470] XFS (dm-6): device supports 1024 byte sectors (not 512)
Jan 4 17:40:50 debian10 kernel: [42150.332581] XFS (dm-6): device supports 1024 byte sectors (not 512)
Jan 4 17:40:51 debian10 kernel: [42151.334976] XFS (dm-6): device supports 1024 byte sectors (not 512)
Jan 4 17:40:52 debian10 kernel: [42152.337999] XFS (dm-6): device supports 1024 byte sectors (not 512)
And the mountfs loop only ends when the merge has completed, hence the question of if it really works in the background?
The merge ends when the next command is about to be executed, where I am trying to reduce the disk from the volume group
2022-01-04.17:40:53 VGREDUCE
And there are no indication of any file system errors either
Jan 4 17:40:53 debian10 kernel: [42153.374758] XFS (dm-6): Mounting V5 Filesystem
Jan 4 17:40:53 debian10 kernel: [42153.378430] XFS (dm-6): Starting recovery (logdev: internal)
Jan 4 17:40:53 debian10 kernel: [42153.378741] XFS (dm-6): Ending recovery (logdev: internal)
Jan 4 17:41:53 debian10 kernel: [42213.622453] block nbd3: NBD_DISCONNECT
I have not analyzed into this more deeply, but could it be that LVM merge has a pre-phase step, where it has to scan all the blocks first before actually starting a merge?
Because that can explain why, as our disks are emulated block device coming from the nmd devices
Or do you have any tips that can lead us into the right track?
Regards Tomas