isplist@xxxxxxxxxxxx wrote:
Jan 22 11:22:44 cweb92 lvm[8635]: locking_type not set correctly in lvm.conf,
I just noticed this in my lvm.conf;
# Type of locking to use. Defaults to file-based locking (1).
# Turn locking off by setting to 0 (dangerous: risks metadata corruption
# if LVM2 commands get run concurrently).
locking_type = 1
# Local non-LV directory that holds file-based locks while commands are
# in progress. A directory like /tmp that may get wiped on reboot is OK.
locking_dir = "/var/lock/lvm"
It used to be;
locking_type = 2
locking_library = "/usr/lib/liblvm2clusterlock.so"
What is confusing is that I did not change this nor did I upgrade anything and
it happened after this hardware crash? What in the world does it all mean?
Mike
Hi Mike,
For your situation, you want locking_type = 2. Hard to say how it
changed from 2 to 1.
Could you have installed an RPM that overwrote it or something?
I'm not an lvm2 guy, but it should not change by itself. Perhaps an
fsck after the crash
found /etc/lvm/lvm.conf to be bad and deleted it, and then lvm2 picked
up the pieces
and started you out with a new default lvm.conf. Hard to speculate on that.
I still think the lvm commands shouldn't segfault. If you're not
running the latest
and greatest lvm2 code, those developers might have already found and
fixed the
segfault. You could still do some bugzilla searches and see if it's a
known issue.
If you're only interested in getting back to business, I'd say change it
back to 2 and
see if you can function normally again.
Regards,
Bob Peterson
Red Hat Cluster Suite
--
Linux-cluster mailing list
Linux-cluster@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/linux-cluster
