[lvm-devel] [PATCH LVM2 v1 1/2] blkdeactive: Introduce option "forcevg" to forcibly deactivate VG

[Zdenek Kabelac]

Dne 25. 02. 21 v 13:39 Leo Yan napsal(a):
> Hi Zdenek,
> 
> On Thu, Feb 25, 2021 at 01:01:36PM +0100, Zdenek Kabelac wrote:
>> Dne 25. 02. 21 v 12:04 Leo Yan napsal(a):
>>> From: Zhang Huan <zhanghuan at huayun.com>
>>>
>>> This patch introduces new option "forcevg" for LVM, the main purpose is
>>> to flush in-flight I/O operations and replace the LV's device mapper
>>> table with 'error' target, this is accomplished by using command
>>> "dmsetup wipe_table".
>>
>> Hi
>>
>> For this moment - I'd prefer different solution in upstream.
>>
>> We should first see what are the chance to support forcible deactivation
>> within lvm2 code directly.
>>
>> This 'out-of-control' external logic may cause significant data loss
>> breakages - as the external tools have not so good idea about connections
>> between targets.
>>
>> There need to be something like: vgchange -an --force --yes
> 
> I have to admit that I am not familiar with the LVM internal, so it's
> quite possible that my understanding is not mature, but let me bring
> up the question.
> 
> If we use "vgchange -an --force --yes" or "lvchange" commands to
> disable VG or LV, seems to me this is likely to cause the egg and
> chicken problem, and at the end it easily leads to "deadlock" result.

lvm supports options --nolocking  --noudevsync
so there should be a mechanism to bypass many problem when necessary -

it's just we shouldn't use the biggest hammer as the first thing in the row.

the option --force should be able to 'gradualy' raise 'actions'.

Depending on what kind of trouble is user expecting.

But under-cutting device with error target should be definitely the last.

> The reason is when the lock manager invokes "lvmlockctl --kill" to
> kill VG, usually this means the lock manager has detected the drive
> failures (e.g. the sanlock lock manager finds it cannot renew lease
> due to the I/O failures), for this case, it's likely the node has no
> chance to access metadata anymore.  So if we use "vgchange" command to
> disable VG, it's possible to stuck for long time.

Yep - there likely need to be also improved mechanism to recognize locking
manager is in some limbo state.

Zdenek