Hi Ulrich,
> However I feel the best thing would eb to fix the perfomance issues in the > LVM commands, rather than not using them. I agree. But given the natural internal logic of vgck (and other LVM commands as well), it's unavoidable slow on large setup. So I think not using them is good workaround of us now ;). > 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. Yes, I think so too. VG metadata is almost always checked by LVM commands. > The paranoid should monitor individual LVs anyway instead of just monitoring > the VG. I think you mean all of the individual LVs in the VG. ;) > 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: The check actually returns success if any LV of the VG is available. I'm always wondering the purpose to do regular LVM monitoring. If it's not running fine, those depend on it will fail (even dmeventd will react on some of the problems). If nothing depends on LVM, why should we care the health of LVM then ;) _______________________________________________ Linux-HA mailing list [email protected] http://lists.linux-ha.org/mailman/listinfo/linux-ha See also: http://linux-ha.org/ReportingProblems
