> -----Original Message----- > From: linux-cluster-bounces@xxxxxxxxxx [mailto:linux-cluster-bounces@xxxxxxxxxx] > On Behalf Of Geovanis, Nicholas > Sent: Wednesday, December 07, 2011 12:23 PM > >> We ditched CLVM but kept GFS. It felt like CLVM had too many limitations to make > it worthwhile. > > Would you elaborate on this for me please? I understand the "damn, forgot to start > clvmd on that node...." type of annoyance, but what were your burning issues? I'm not > convinced that there's a performance drawback which is specifically clvmd-related, but > maybe I'm naïve. Thanks....Nick G At the time there was no snapshot support. That was the big missing feature for us. We also tried using pvmove, and had problems with it. It was very slow, and eventually stopped altogether complaining about a lock. I tried activating LV's exclusively and it didn't help. Later I found that that in drastic situations, I could remove the "clustered" bit temporarily, make my changes, then revert to a clustered volume (recognizing this is dangerous when the volume is shared). At times, running simple commands like "lvs" became very slow, or stopped completely. Restarting the node would clear it up. When this occurred, the cluster would otherwise appear normal. To be fair, it was a few years ago when we were evaluating this, on 5.2 I think. It's likely some of the bugs have been worked out. We didn't have a lot of motivation to work through them as long as we could fall back on the SAN for the functionality we needed. Red Hat has a tendency I think to release features just a little before they are ready (sometimes with caveats, like the GFS2 preview release). This is good for users who are evaluating the technology. For production however, we need stability above all else. Since about 5.3, GFS has worked very well for us. Based on our experience with early 5.x releases, I'm not in any hurry to move to 6.x. -Jeff -- Linux-cluster mailing list Linux-cluster@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/linux-cluster
