3 Commits

Author	SHA1	Message	Date
David Teigland	f32fd1fcb9	lvmlockd: adopt options ... Lock adoption is not part of standard command behavior, but can be used for manual recovery or cleanup from unexpected failure cases. Like other lockopt values, they are hidden options for --lockopt. Different lock managers will behave differently. Adopting locks with lvmlockd -A1 is more accurate and automatic. --lockopt adoptls . for vgchange --lockstart . adopt existing ls, or fail if no existing lockspace is found --lockopt adoptgl | adoptvg | adoptlv . for commands using lvmlockd locks . adopt orphan gl/vg/lv lock, or fail the lock request if no orphan lock is found . will fail if orphan lock exists with a different lock mode . command may still continue with a failed shared lock request --lockopt adopt . for lockstart or any command using lvmlockd locks . adopt existing lockspace, or start lockspace if none exists . adopt orphan gl/vg/lv lock, or acquire new lock if no orphan found . will fail if orphan lock exists with a different lock mode . command may still continue with a failed shared lock request . with dlm this option only works for ls	2024-06-27 13:29:03 -05:00
Zdenek Kabelac	ed59b50512	cleanup: free already does NULL check ... Drop extra check for NULL before calling free(). Also drop zeroing data that will be free().	2021-09-15 15:24:56 +02:00
Leo Yan	7a8b7b4add	lvmlockd: idm: Introduce new locking scheme ... Alongside the existed locking schemes of DLM and sanlock, this patch is to introduce new locking scheme: In-Drive-Mutex (IDM). With the IDM support in the drive, the locks are resident in the drive, thus, the locking lease is maintained in a central place: the drive firmware. We can consider this is a typical client-server model, every host (or node) in the server cluster launches the request for leasing mutex to a drive firmware, the drive firmware works as an arbitrator to grant the mutex to a requester and it can reject other applicants if the mutex has been acquired. To satisfy the LVM activation for different modes, IDM supports two locking modes: exclusive and shareable. Every IDM is identified with two IDs, one is the host ID and another is the resource ID. The resource ID is a unique identifier for what the resource it's protected, in the integration with lvmlockd, the resource ID is combined with VG's UUID and LV's UUID; for the global locking, the bytes in resource ID are all zeros, and for the VG locking, the LV's UUID is set as zero. Every host can generate a random UUID and use it as the host ID for the SCSI command, this ID is used to clarify the ownership for mutex. For easily invoking the IDM commands to drive, like other locking scheme (e.g. sanlock), a daemon program named IDM lock manager is created, so the detailed IDM SCSI commands are encapsulated in the daemon, and lvmlockd uses the wrapper APIs to communicate with the daemon program. This patch introduces the IDM locking wrapper layer, it forwards the locking requests from lvmlockd to the IDM lock manager, and returns the result from drives' responding. One thing should be mentioned is the IDM's LVB. IDM supports LVB to max 7 bytes when stores into the drive, the most significant byte of 8 bytes is reserved for control bits. For this reason, the patch maps the timestamp in macrosecond unit with its cached LVB, essentially, if any timestamp was updated by other nodes, that means the local LVB is invalidate. When the timestamp is stored into drive's LVB, it's possbile to cause time-going-backwards issue, which is introduced by the time precision or missing synchronization acrossing over multiple nodes. So the IDM wrapper fixes up the timestamp by increment 1 to the latest value and write back into drive. Currently LVB is used to track VG changes and its purpose is to notify lvmetad cache invalidation when detects any metadata has been altered; but lvmetad is not used anymore for caching metadata, LVB doesn't really work. It's possible that the LVB functionality could be useful again in the future, so let's enable it for IDM in the first place. Signed-off-by: Leo Yan <leo.yan@linaro.org>	2021-05-20 16:00:59 -05:00