David Teigland 32e22a0037 lvmlockd: rescan lockd VG in two new cases ... Previously, a command would only rescan a lockd VG when lvmetad returned the "vg_invalid" flag indicating that the cached copy was invalid (which is done by lvmlockd.) This is still the only usual reason for rescanning a lockd VG, but two new special cases are added where we also do the rescan: . When the --shared option is used to display lockd VGs from hosts not using lvmlockd. This is the same case as using --foreign to display foreign VGs, but --shared was missing the corresponding bits to rescan the VGs. . When a lockd VG is allowed to be read for displaying after failing to acquire the lock from lvmlockd. In this case, the usual mechanism for validating the cache is missed, so assume the cache would have been invalidated. (This had been a previous todo item that was lost during other cleanup.) These were long-standing todos that were lost track of.		2015-08-27 10:27:24 -05:00
..
toolcontext.c	toolcontext: do not set cmd->initialized_connections = 0 on destroy_toolcontext	2015-08-03 16:17:17 +02:00
toolcontext.h	lvmlockd: rescan lockd VG in two new cases	2015-08-27 10:27:24 -05:00