locking: use lock file timestamps to detect vg changesdev-dct-lockfile

A reporting command that is run concurrently with another
command modifying a VG may report either the old or new
VG state.  This flexibility means the reporting command
could be optimized to report metadata that was read prior
to taking the VG lock.

Using lock file timestamps, that window can be closed so
that metadata reported is always consistent with the held
VG lock.  In some cases, this additional consistency will
avoid warnings that could be produced when the command
compares the metadata with the dm kernel state.

The end result is that the optimization is used (to read
disks only once) and the reported metadata is consistent
with the dm kernel state, even if a concurrent command
is making changes.

A reporting command will now save the VG lock file
timestamps prior to scanning disks.  The VG metadata that
is read while scanning disks is saved in memory.

After the scan, when reporting each VG, the command will
lock the VG, and then check the lock file timestamp again.
If the timestamp is unchanged, then the metadata saved
from the scan is unchanged and is reused to report the VG.
If the timestamp has changed, then another command has
modified the metadata since the scan, and the metadata is
reread from disk prior to reporting it.

Changes to lock file handling to support this:
- lock files are no longer unlinked and recreated by every
  lvm command, but are left in place.
- a command modifying a VG (holding an exclusive flock)
  will update the lock file timestamp before unlocking it.

1 files changed, 9 insertions, 0 deletions

diff --git a/lib/label/label.c b/lib/label/label.c
index 05986cbe7..69d6d67fe 100644
--- a/lib/label/label.c
+++ b/lib/label/label.c
@@ -1046,6 +1046,15 @@ int label_scan(struct cmd_context *cmd)
 	_prepare_open_file_limit(cmd, dm_list_size(&scan_devs));
 
 	/*
+	 * Read and save the timestamps from VG lock files.  The lock file
+	 * timestamp is updated when a command releases an exclusive lock
+	 * (indicating it has changed the VG.)  So, the timestamps can be
+	 * checked later to detect if another command has changed the VG since
+	 * our label scan.
+	 */
+	file_lock_save_times(cmd);
+
+	/*
 	 * Do the main scan.
 	 */
 	_scan_list(cmd, cmd->filter, &scan_devs, NULL);