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@xxxxxxxxxx https://listman.redhat.com/mailman/listinfo/linux-lvm read the LVM HOW-TO at http://tldp.org/HOWTO/LVM-HOWTO/
