[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