Gitweb: https://sourceware.org/git/?p=lvm2.git;a=commitdiff;h=2036608423117626eb190…
Commit: 2036608423117626eb1905b38e09c767983b2ef4
Parent: 78afe75b08c01e70d52e42b62acf0d6eab7874dc
Author: David Teigland <teigland(a)redhat.com>
AuthorDate: Wed May 22 11:55:48 2019 -0500
Committer: David Teigland <teigland(a)redhat.com>
CommitterDate: Wed May 22 11:55:48 2019 -0500
tests: pvscan-cache try to fix teardown problems
teardown after the test was failing, probably because
of uncoordinated udev actions running on the test
system. Try to avoid this by doing some work before
teardown.
---
test/shell/pvscan-cache.sh | 3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/test/shell/pvscan-cache.sh b/test/shell/pvscan-cache.sh
index e0576f9..8788594 100644
--- a/test/shell/pvscan-cache.sh
+++ b/test/shell/pvscan-cache.sh
@@ -75,4 +75,7 @@ aux enable_dev "$dev2"
pvscan --cache
check pv_field "$dev1" vg_name "$vg1"
+vgchange -an $vg1
+lvremove $vg1/$lv1
+
vgremove -ff $vg1
Gitweb: https://sourceware.org/git/?p=lvm2.git;a=commitdiff;h=c733e9644537c7901caf2…
Commit: c733e9644537c7901caf245c1b3fdcdeba76cc12
Parent: 3669c33af4279c93c8a9104de9501ba9cf6a2745
Author: David Teigland <teigland(a)redhat.com>
AuthorDate: Tue May 21 15:14:24 2019 -0500
Committer: David Teigland <teigland(a)redhat.com>
CommitterDate: Tue May 21 15:14:24 2019 -0500
man: updates to lvmlockd
- remove references to adopting locks which is not used
- move some sanlock-specific info out of a general section
- remove info about doing automatic lockstart by the system
since this was never used (the resource agent does it)
---
man/lvmlockd.8_main | 61 ++++++++++++--------------------------------------
1 files changed, 15 insertions(+), 46 deletions(-)
diff --git a/man/lvmlockd.8_main b/man/lvmlockd.8_main
index 3f0e3ed..b917d93 100644
--- a/man/lvmlockd.8_main
+++ b/man/lvmlockd.8_main
@@ -76,9 +76,6 @@ For default settings, see lvmlockd -h.
.I seconds
Override the default sanlock I/O timeout.
-.B --adopt | -A 0|1
- Adopt locks from a previous instance of lvmlockd.
-
.SH USAGE
@@ -261,6 +258,16 @@ does for foreign VGs.
.SS creating the first sanlock VG
+When use_lvmlockd is first enabled in lvm.conf, and before the first
+sanlock VG is created, no global lock will exist. In this initial state,
+LVM commands try and fail to acquire the global lock, producing a warning,
+and some commands are disallowed. Once the first sanlock VG is created,
+the global lock will be available, and LVM will be fully operational.
+
+When a new sanlock VG is created, its lockspace is automatically started on
+the host that creates it. Other hosts need to run 'vgchange --lock-start'
+to start the new VG before they can use it.
+
Creating the first sanlock VG is not protected by locking, so it requires
special attention. This is because sanlock locks exist on storage within
the VG, so they are not available until after the VG is created. The
@@ -288,19 +295,7 @@ See below for more information about managing the sanlock global lock.
.SS using shared VGs
-There are some special considerations when using shared VGs.
-
-When use_lvmlockd is first enabled in lvm.conf, and before the first
-shared VG is created, no global lock will exist. In this initial state,
-LVM commands try and fail to acquire the global lock, producing a warning,
-and some commands are disallowed. Once the first shared VG is created,
-the global lock will be available, and LVM will be fully operational.
-
-When a new shared VG is created, its lockspace is automatically started on
-the host that creates it. Other hosts need to run 'vgchange --lock-start'
-to start the new VG before they can use it.
-
-From the 'vgs' command, shared VGs are indicated by "s" (for shared) in
+In the 'vgs' command, shared VGs are indicated by "s" (for shared) in
the sixth attr field, and by "shared" in the "--options shared" report
field. The specific lock type and lock args for a shared VG can be
displayed with 'vgs -o+locktype,lockargs'.
@@ -379,31 +374,6 @@ activation {
.fi
-.SS automatic starting and automatic activation
-
-When system-level scripts/programs automatically start VGs, they should
-use the "auto" option. This option indicates that the command is being
-run automatically by the system:
-
-vgchange --lock-start --lock-opt auto [<vgname> ...]
-
-The "auto" option causes the command to follow the lvm.conf
-activation/auto_lock_start_list. If auto_lock_start_list is undefined,
-all VGs are started, just as if the auto option was not used.
-
-When auto_lock_start_list is defined, it lists the shared VGs that should
-be started by the auto command. VG names that do not match an item in the
-list will be ignored by the auto start command.
-
-(The lock_start_list is also still used to filter VG names from all start
-commands, i.e. with or without the auto option. When the lock_start_list
-is defined, only VGs matching a list item can be started with vgchange.)
-
-The auto_lock_start_list allows a user to select certain shared VGs that
-should be automatically started by the system (or indirectly, those that
-should not).
-
-
.SS internal command locking
To optimize the use of LVM with lvmlockd, be aware of the three kinds of
@@ -411,8 +381,8 @@ locks and when they are used:
.I Global lock
-The global lock s associated with global information, which is information
-not isolated to a single VG. This includes:
+The global lock is associated with global information, which is
+information not isolated to a single VG. This includes:
\[bu]
The global VG namespace.
@@ -456,7 +426,7 @@ held only while an LVM command is running.)
.I lock retries
-If a request for a Global or VG lock fails due to a lock conflict with
+If a request for a global or VG lock fails due to a lock conflict with
another host, lvmlockd automatically retries for a short time before
returning a failure to the LVM command. If those retries are
insufficient, the LVM command will retry the entire lock request a number
@@ -579,8 +549,7 @@ necessary locks.
.B lvmlockd failure
If lvmlockd fails or is killed while holding locks, the locks are orphaned
-in the lock manager. lvmlockd can be restarted with an option to adopt
-locks in the lock manager that had been held by the previous instance.
+in the lock manager.
.B dlm/corosync failure