Red Hat Bugzilla – Bug 189751
cannot mount local lvm2 partition with lvm2-cluster
Last modified: 2014-06-18 03:35:20 EDT
Created attachment 128144 [details]
first stab at a patch to fix problem
Here's a first stab at a patch to fix this problem. I tested the rc.sysinit
piece by changing all invocations of lvm.static in it to just plain "lvm". This
worked, but (of course) would not if /usr were on a different filesystem.
So, I think this patch should do the trick, but is dependent BZ 165787 getting
Aside from the fact that it changes the operation from one command total to nine
commands per volume, it's duplicating logic that it appears it could be easily
handled in the LVM code itself; the code itself has the knowledge of what sort
of locking each volume does, so it should be easy enough to specify an
additional option to only start ones that don't use cluster locking.
No argument on the prettiness of this, when I discussed this with Alasdair over
the weekend, this was basically what he suggested (though he did mention maybe
adding some filtering code to "vgs" to cut down on some of the string slicing.
My initial thought was to basically do this, and just vgchange -ay each VG that
wasn't clustered, but AGK suggested this approach since activating LV's that are
already activated is a waste.
Also, unfortunately, with the current LVM2 code, the locking settings are
global. It doesn't currently have any conception of what sort of locking each VG
should do (though we might presumably be able to add something like an
--ignore-clustered flag or something).
That's what I'm suggesting, sorry if I used the wrong terminology - the tool
knows what is clustered, it should be easily enough to exclude.
Ok, I've just posted a patch to the other BZ (165787) that adds a
--skipclustered flag to vgchange. If Alasdair finds that patch reasonable, then
we should just be able to add that flag to the vgchange line here.
This request was evaluated by Red Hat Product Management for inclusion in a Red
Hat Enterprise Linux maintenance release. Product Management has requested
further review of this request by Red Hat Engineering, for potential
inclusion in a Red Hat Enterprise Linux Update release for currently deployed
products. This request is not yet committed for inclusion in an Update
Made some changes upstream (in reverse order) which I hope will help:
Don't attempt automatic recovery without proper locking.
When using local file locking, skip clustered VGs.
Add fallback_to_clustered_locking and fallback_to_local_locking parameters.
lvm.static uses built-in cluster locking instead of external locking.
Don't attempt to load shared libraries if built statically.
So the hope is that, with the new default behaviour, provided the command *only*
references a specific non-clustered VG it will now be able to run successfully.
But initscripts is likely still to need to add an extra parameter to the lvm
command - this bz depends on the lvm2 one.
Should be reproducible by QE based on test case given in comment from
firstname.lastname@example.org on 2006-04-20 15:26 EST. Adding qa_ack+ for 4.5
Is there better information on the LVM side as to what, if any, initscripts
changes may be needed?
I'll defer that question to Alasdair since he did the upstream changes.
I'm lost with what the outstanding problem is on this bugzilla.
Please test with the latest lvm2/lvm2-cluster packages (currently being built)
2.02.15-1 and report back. If there are still problems, there should now be
enough command-line configurability to work around them.
OK, can someone put this info in the original LVM2 bug? (167587)
Should this bug just be closed?
Sounds like the lvm2 packages themselves fix this without any need for
initscripts changes. Going ahead and closing this as notabug.