Hi, On Mon, Nov 14, 2011 at 01:11:02PM +0100, Lars Ellenberg wrote: > On Mon, Nov 14, 2011 at 10:54:47AM +0100, Ulrich Windl wrote: > > Hello! > > > > We see significant performance issues with the LVM RA when writing to > > an ext3 filesystem with default journaling and berriers enabled. So > > anything that speeds up the RA monitor operation (it needs up to 90 > > seconds here accasionally) would be appreciated. > > > > However I feel the best thing would eb to fix the perfomance issues in > > the LVM commands, rather than not using them. > > > > For the vgck: If the VG metadata are checked during startup, a > > periodic re-check seems unnecessary to me: During normal (use) > > operation of the VG's LVs (that's the typical use case for VGs in a > > cluster configuration) the (checkable) metadata don't change a lot, so > > it may not make much sense. I'd rely on the kernel to shutdown (i.e. > > put into read-only) a faulty VG anyway. > > > > The paranoid should monitor individual LVs anyway instead of just > > monitoring the VG. > > > > Eventually the documentations says: > > "The 'monitor' operation reports whether the volume seems present" > > > > So probably a [ -r /dev/mapper/VG-name ] should also do ;-) > > As you usually have something *using* it, Filesystem, VirtualDomain or > whatever, monitoring that should be enough. > Just drop monitoring of the VG primitive, > there is not much point doing so anyways.
Good idea :) > > I see that vgck is used even after LVM_status was successful; > > LVM-status uses vgdisplay to check the status. There's another funny > > thing in my version (SLES11 SP1): The check is: > > vgdisplay -v $1 2>&1 | grep -i 'Status[ \t]*available' 2>&1 >/dev/null > > > > but there is not "available status" for the VG, only for the LV! > > # vgdisplay -v VG |grep Status > > Using volume group(s) on command line > > Finding volume group "VG" > > Do not wait for udev on information only command > > Do not wait for udev on information only command > > Do not wait for udev on information only command > > Do not wait for udev on information only command > > Do not wait for udev on information only command > > Do not wait for udev on information only command > > Do not wait for udev on information only command > > Do not wait for udev on information only command > > Do not wait for udev on information only command > > Do not wait for udev on information only command > > Do not wait for udev on information only command > > Do not wait for udev on information only command > > Do not wait for udev on information only command > > Do not wait for udev on information only command > > Do not wait for udev on information only command > > Do not wait for udev on information only command > > Do not wait for udev on information only command > > Do not wait for udev on information only command > > Do not wait for udev on information only command > > VG Status resizable > > LV Status available > > LV Status available > > PV Status allocatable > > > > So the VG is not "available", but "resizable". Well, there are many > > ways to write a resource agent, but only few of them are correct... Hmm, did you actually have a problem here? Or do you just think that there could be one? > Thats actually ok: if the "VG" is "active" its "LV"s are "available". > Well, unless you have a VG without any LVs, which, again, is a bit pointless. > Just compare the output of an active an an inactive VG. Xin Wei suggested to drop vgck from the monitor operation and submitted the patch. Thanks, Dejan _______________________________________________ Linux-HA mailing list [email protected] http://lists.linux-ha.org/mailman/listinfo/linux-ha See also: http://linux-ha.org/ReportingProblems
