mirror of
git://sourceware.org/git/lvm2.git
synced 2024-12-21 13:34:40 +03:00
man lvmlockd: add section about first sanlock VG
Add a section specifically about creating the first sanlock VG.
This commit is contained in:
parent
869c0bdeb8
commit
43d6b5b375
@ -298,6 +298,32 @@ LVM commands request locks from clvmd to use the VG.
|
||||
|
||||
.P
|
||||
|
||||
.SS creating the first sanlock VG
|
||||
|
||||
Creating the first sanlock VG is not protected by locking and requires
|
||||
special attention. This is because sanlock locks exist within the VG, so
|
||||
they are not available until the VG exists. The first sanlock VG will
|
||||
contain the "global lock".
|
||||
|
||||
.IP \[bu] 2
|
||||
While running vgcreate for the first sanlock VG, ensure that the PV being
|
||||
used is not used by another LVM command. Allocation of shared PVs is
|
||||
usually protected by the global lock, but this cannot be done for the
|
||||
first sanlock VG which will hold the global lock.
|
||||
|
||||
.IP \[bu] 2
|
||||
While running vgcreate for the first sanlock VG, ensure that the VG name
|
||||
being used is not used by another LVM command. Uniqueness of VG names is
|
||||
usually ensured by the global lock.
|
||||
|
||||
.IP \[bu] 2
|
||||
Because the first sanlock VG will contain the global lock, this VG needs
|
||||
to be accessible to all hosts that will use sanlock shared VGs. All hosts
|
||||
will need to use the global lock from the first sanlock VG.
|
||||
|
||||
See below for other special cases related to moving the global lock.
|
||||
|
||||
|
||||
.SS using lockd VGs
|
||||
|
||||
There are some special considerations when using lockd VGs.
|
||||
@ -479,9 +505,7 @@ global/lvmlockd_lock_retries before failing. If a request for an LV lock
|
||||
fails due to a lock conflict, the command fails immediately.
|
||||
|
||||
|
||||
.SS sanlock global lock
|
||||
|
||||
There are some special cases related to the global lock in sanlock VGs.
|
||||
.SS managing the global lock in sanlock VGs
|
||||
|
||||
The global lock exists in one of the sanlock VGs. The first sanlock VG
|
||||
created will contain the global lock. Subsequent sanlock VGs will each
|
||||
@ -526,14 +550,7 @@ A small sanlock VG dedicated to holding the global lock can avoid the case
|
||||
where the GL lock must be manually enabled after a vgremove.
|
||||
|
||||
|
||||
.SS sanlock VG usage
|
||||
|
||||
There are some special cases related to using a sanlock VG.
|
||||
|
||||
vgremove of a sanlock VG will fail if other hosts have the VG started.
|
||||
Run vgchange \-\-lock-stop <vgname> on all other hosts before vgremove.
|
||||
(It may take several seconds before vgremove recognizes that all hosts
|
||||
have stopped.)
|
||||
.SS internal lvmlock LV
|
||||
|
||||
A sanlock VG contains a hidden LV called "lvmlock" that holds the sanlock
|
||||
locks. vgreduce cannot yet remove the PV holding the lvmlock LV. To
|
||||
@ -543,6 +560,12 @@ change the VG lock type back to "sanlock".
|
||||
To place the lvmlock LV on a specific device, create the VG with only that
|
||||
device, then use vgextend to add other devices.
|
||||
|
||||
vgremove of a sanlock VG will fail if other hosts have the VG started.
|
||||
Run vgchange \-\-lock-stop <vgname> on all other hosts before vgremove.
|
||||
(It may take several seconds before vgremove recognizes that all hosts
|
||||
have stopped.) This is necessary because while a host has a sanlock VG
|
||||
started, it is using the internal lvmlock LV.
|
||||
|
||||
|
||||
.SS shared LVs
|
||||
|
||||
|
Loading…
Reference in New Issue
Block a user