Re: [linux-lvm] lvs activation columns are confusing for shared volume groups

[David Teigland <teigland@redhat.com>]

On Sat, Oct 22, 2022 at 02:05:39PM +0200, corubba wrote:
> Hi,
> 
> in 2018 there was a change [0] that removed clvmd support from the LV
> active columns of the `lvs` tool. The column `lv_active_remotely` is
> always unset/empty, and the columns `lv_active_locally` and
> `lv_active_exclusively` are all simply coupled to the activation state
> of the LV. For a local VG this all fine and dandy, but it gets confusing
> for shared VGs. Take this example of a 2-node shared VG setup using
> lvmlockd+sanlock:

> As soon as a LV is active, `lvs` will report it as "active exclusively"
> regardless of whether it was activated in exclusive or shared mode. To
> get accurate information, you have to check the lock-mode on that LV
> using `lvmlockctl --info`. And as noted above, it is never reported as
> "active remotely" even if it is. It took me a while to realise this.

Hi, thanks for the report, these are some good questions.

"active remotely": lvmlockd is unable to passively report the remote
active or locked state of an LV.  A node only knows if it has the LV
active or locked itself.  One node can find out if other nodes have the LV
locked only by attempting to lock the LV and seeing if it fails.  This
interferes with actual usage, so it wouldn't be appropriate to do this
lock-to-check-state automatically.  Also, an LV is locked due to being
either active or modified, so calling it the "active" state would not be
entirely accurate.

"active exclusively": lvm could be improved here by not setting this field
when lvmlockd holds a shared lock on the LV.  The lvm reporting would need
to ask lvmlockd what lock mode was held (_query_lock_lv.)  The same caveat
applies about calling it the "active" state, although we could combine the
lock state with the active state to exclude the case where the LV is
locked exclusively for modification while inactive.

> I am willing to spend some time on this to develop a fix, but I am
> unsure in what direction to move.

I think a patch would be useful to improve lv_active_exclusively
(_lvactiveexclusively_disp) to consider the state from both lv_is_active()
and query_lock_lv().

> deprecation note in the docs for these columns would be appropriate. Or
> more drastically, remove these columns altogether.

The "active remotely" deprecation could be added to the lvmlockd man page
under "changes from clvmd".

> The downside is the output of `lvmlockctl` in its current state isn't
> very human-readable, especially compared to lvs.

Right, it's for debugging so any useful info should be added to lvs.

Dave
_______________________________________________
linux-lvm mailing list
linux-lvm@redhat.com
https://listman.redhat.com/mailman/listinfo/linux-lvm
read the LVM HOW-TO at http://tldp.org/HOWTO/LVM-HOWTO/