[Linux-cluster] A few GFS newbie questions: journals, etc

Jason Lanclos jason at selu.edu
Wed Jul 6 14:17:32 UTC 2005


On Tuesday 05 July 2005 11:04 pm, Fajar A. Nugraha wrote:
> Jason Lanclos wrote:
> 
> >>>You shouldn't even need CLVM if you don't intend to muddle with
> >>>partitions or cross-mount the file systems.  You'll lose resizing, but
> >>>in doing so, your clients no longer need to be cluster participants.
> >>>      
> >>>
> >
> >CLVM is cool, but its pretty much useless until LVM2 actually implements 
> >pvresize or a pvextend. 
> >
> What's wrong with vgextend?

Nothings wrong with vgextend.. but its useless when i want to extend a pv.


> 
> >One of the main advantages of having a SAN is being 
> >able to add space to a volume (LUN)   Currently when we expand a volume on 
> >the san, we have to unmount the filesystem, rescan the LUNs, then run fdisk 
> >on that volume, delete the partition entry, and recreate it to use all the 
> >space.. then at that point we can run ext2online / gfs_grow to resize the 
> >filesystem.
> >
> >  
> >
> A simpler method will be create a NEW LUN, scan it, pvcreate, add it to 
> existing VG with vgextend, and extend your volume lvextend. At least you 
> don't have to mess with existing partitions.

Ok.. what happens when you reach the max LUNs or max partitions???
And I can only imagine the administration nightmare it would be to manage with several
volumes spread over multiple LUNs. The whole point of a SAN is to simplify management of data storage.
And what about copy/swap? Spreading a volume over multiple LUNs would make using this feature of the SAN impossible / very
dangerous to do while volumes are mounted.
So.. One Volume, One LUN, One partition is the easiest way.
There are prolly a thousand different ways to "make it work",
but I wouldn't consider that part of the whole "Red Hat Enterprise Linux" concept. 

I know I'm not the 1st person to run into this issue.. 
so rather than having numerous work arounds, why not just implement pvresize/pvextend to do this?

  https://www.redhat.com/archives/linux-lvm/2003-July/msg00038.html

Oh.. and there's already a man page for it.. even though its not implemented in LVM2:
  http://mandoc.etopian.net/man/linux/8/pvresize

And a work around that I'd be reluctant using on a production system:
  http://www.redhat.com/archives/linux-lvm/2004-December/msg00049.html





> 
> >I would be VERY nice if pvresize / pvextend existed, that way one could expand 
> >the volume on the SAN, 
> >
> My IBM SAN can't expand exisiting volume on the SAN. It's not like I 
> need it though. The above solution works better.

XioTech Magnitude expands volumes with no problem.. Its one of the reasons we chose it for our
SAN.

> 
> >rescan LUNs on each cluster member, run pvresize / 
> >pvextend, run lvextend and then gfs_grow and call it a day.
> >
> >  
> >
> My only problem (for now) is I can't rescan LUNs without removing HBA 
> modules (thus unmounting filesystems or restarting the server).

I'm not sure if it will work with your FC card, but I've used the following script
a few times with a qlogic card and it worked.
  http://www.fifi.org/cgi-bin/man2html/usr/share/man/man8/rescan-scsi-bus.sh.8.gz


> If you  
> can rescan LUNs online, it's a simple method of pvcreate, vgextend, 
> lvextend, gfs_grow, and call it a day.
> 
> >I mentioned this at the RedHat summit, and got a few puzzled looks, 
> >
> I wonder why :-D

> 
> Regards,
> 
> Fajar
> 
> --
> Linux-cluster mailing list
> Linux-cluster at redhat.com
> http://www.redhat.com/mailman/listinfo/linux-cluster
> 

-- 
Jason Lanclos                                        
Systems Administrator                                 
Red Hat Certified Engineer        
Southeastern Louisiana University		     




More information about the Linux-cluster mailing list