Storage space partition

[Bob McClure Jr]

On Thu, Apr 13, 2006 at 01:53:35PM -0400, Nair, Murlidharan T wrote:
> 
> 
> -----Original Message-----
> From: redhat-install-list-bounces at redhat.com
> [mailto:redhat-install-list-bounces at redhat.com] On Behalf Of Bob McClure
> Jr
> Sent: Thursday, April 13, 2006 11:34 AM
> To: Getting started with Red Hat Linux
> Subject: Re: Storage space partition
> 
> If you please, we prefer bottom posting.  See
> 
> http://en.wikipedia.org/wiki/Top-posting
> 
> I'll reorder this.
> 
> On Thu, Apr 13, 2006 at 11:06:35AM -0400, Nair, Murlidharan T wrote:
> > 
> > -----Original Message-----
> > From: redhat-install-list-bounces at redhat.com
> > [mailto:redhat-install-list-bounces at redhat.com] On Behalf Of Bob
> McClure
> > Jr
> > Sent: Thursday, April 13, 2006 10:01 AM
> > To: Getting started with Red Hat Linux
> > Subject: Re: Storage space partition
> > 
> > On Thu, Apr 13, 2006 at 09:49:24AM -0400, Nair, Murlidharan T wrote:
> > > I have just completed the installation of Linux and configured the
> > > storage array as RAID5. The total capacity of the storage is about
> > > 600Gb. I am trying to decide on the factors that I should consider
> > when
> > > partitioning it. I only have one server that is connect to my SAN.
> > The
> > > main fact that I am trying to debate is what if the partition that I
> > am
> > > using to store my sql data runs out of space, will storing part of
> my
> > > data on another partition decrease the performance? In which case is
> > it
> > > better to just leave it as one large partition?  I would appreciate
> > you
> > > any comments or suggestions..
> > > 
> > > Thanks ../Murli
> > 
> > Make one partition on the SAN, then make it a physical volume for
> > LVM.  Then divide it up into logical volumes.  Logical volumes are
> > easily resized.  It also has a snapshot capability which helps for
> > backups.
> > 
> > Cheers,
> > -- 
> > Bob McClure, Jr.
> > _______________________________________________
> > 
> > The way I have it now is one virtual disk of size 652GB. Is this
> > equivalent to what you call LVM ?
> 
> No.  Your "virtual disk" is the way your SAN presents a "physical
> disk" to the world.  Establish one partition on that.  (You don't
> really have to do that when using LVM, but this extends to the more
> general case.)  Then establish LVM on that.
> 
> > When logical volumes are resized, I
> > presume it does not affect the already existing data in the volume
> being
> > resized?
> 
> As long as you are making it bigger, no.  After you have resized the
> LV, you will still need to resize the filesystem with (assuming ext2/3
> fs) resize2fs.  If making it smaller, resize the filesystem first,
> then reduce the size of the LV.  Back up your data in case you make a
> mistake.  "man resize2fs" and "man lvresize" for more info.
> 
>  Can you point to a source where I can read a little more about
> > this? I am doing this for the first time. 
> 
> http://en.tldp.org/HOWTO/LVM-HOWTO/index.html
> 
> > Thanks for your comments...
> > Cheers ../Murli
> 
> Cheers,
> -- 
> Bob McClure, Jr.
> _______________________________________________
> 
> If I need to add additional disks and combine the space from those new
> disks to the LVs that I had previously created, can that be done easily?

Yes.  Actually you will be adding the additional "physical" (though
they may well be virtual on the SAN) disks to the "volume group".  And
LVM will allocate new space as it sees fit - it's all in the same pool.

> Does creating the virtual disk format the disk as well? Or do I have to
> do that separately? 

If you mean the SAN's virtual disk, it is now ready to partition with
fdisk or equivalent.  If you mean the LVM volume group, you still need
to create logical volumes, which will need to have mke2fs make
filesystems (what you probably mean by "formatting") on each of them,
just like a partition.

> Cheers ../Murli

Cheers,
-- 
Bob McClure, Jr.             Bobcat Open Systems, Inc.
bob at bobcatos.com             http://www.bobcatos.com
The best things in life aren't things.