On Thu, 2009-12-10 at 13:52 -0700, Andreas Dilger wrote: > > A VG is like a filesystem in that regard, even though they layout > changes much less frequently. If two nodes had a VG imported, and > then one did a grow of an LV (let's say a raw volume for simplicity) > the allocation of that volume would consume PEs from the VG, which > changes the layout on disk. The node that did the resize would > reflect the new size, but the other node has no reason to re-read the > VG layout from disk and would see the old size and PE allocation > maps. If it resized a different LV, it would lead to corruption of > the VG.
Yeah. As an afterthought I had wondered about that. I only recall ever going through resize operations with my shared VG implementation here once and even then I did it all from one node and more than likely did a vgscan on the other node when I was done. > No, the heartbeat code is correct. Agreed. > The whole VG should be under > control of the HA agent, unless you are using the clustered LVM > extensions that Red Hat wrote for GFS2. Yeah. clvmd it seems. > since Lustre/ldiskfs expects sole > ownership of the LVs Individual LVs though. > (and the filesystems therein) there isn't any > benefit to having them imported on 2 nodes at once, but a lot of risk. Cluster-awaring LVM aside, there is if you had one volume group with all of the OSTs for two OSSes in it. Of course, you could isolate your VGs on a per OSS basis but then you start to lose the flexibility LVM brings to the table and also still limit yourself from migrating individual OSTs between OSSes. FWIW, there does seem to be some indication from google that clvmd is FOSS. There is a debian bug report about an initscript for their clvmd package. There is a clvm package in Ubuntu as well. b.
signature.asc
Description: This is a digitally signed message part
_______________________________________________ Lustre-discuss mailing list [email protected] http://lists.lustre.org/mailman/listinfo/lustre-discuss
