[aklug] Re: adding disks to a volset.

From: adam bultman <adamb@glaven.org>
Date: Mon Apr 19 2010 - 20:24:33 AKDT

I'm going to put my comments in with your text.

Thomison, Lee wrote:
> All,
>
> I've got a [multi-user] RHEL5 machine that is running out of disk in the /h=
> ome directory. The volumes are set up as LVM volumes (see below).
> There a=
> re three physical disks set up as RAID5 (yes, I know) on a hardware raid co=
> ntroller.
>
>
REFERENCE CACHE: MISS

I don't get it - what's wrong with three drives in a RAID5 (apart from
performance)?
> I have two 300G drives I can use but I'm wondering what the 'right' thing t=
> o do is? Given that I don't want to rearrange the existing volumes I see =
> I have two choices:
>
> 1. Add the two 300G drives=20
> set them up in a mirror in the hardware controller (not even sure I can do=
> that yet, but you get the idea).
> add them to VolGroup00
> add the extra space to dev/mapper/VolGroup00-LogVol07 (which is /home).
>
>
If the hardware RAID controller is a good one, then use it. If it's a
crappy one, or a slow one, then don't. I can't speak for SATA RAID
cards, but I usually prefer hardware RAID over software RAID. Lots of
people will swear up and down that linux software RAID is super fast,
and that it's almost as good as hardware RAID - well, in the 10 years
I've been a system admin, I've never found a software RAID that performs
even close to the crappiest RAID card I've ever come across. The only
benefit that I know of for linux software RAID1 is that you have two
mountable filesystems with identical data.

An aside: AFAIK, there's no problem with creating an additional RAID
with differently sized drives. ( Even if you had a drive fail in an
existing hardware RAID and you replaced it with a drive that was larger
than the failed disk, the RAID card would simply not use all of the
disk. From what I've found, the days of 'you need a disk of the same
manufacturer with the same cylinders/heads/sectors or it won't work' are
long over. )

All that being said, I'm not a very big fan of taking new disk space
(RAID or not) and using it as physical extents to expand the size of an
existing Logical Volume; it's just 'dirty'. While both of your Physical
Volumes are protected by RAID, it's certainly not a fun situation if one
of your PVs go offline for some reason and the other one stays up.
You're looking at corruption problems at the very least - imagine a bus
reset on your two newer drives, or a bus reset on your older three
drives. Part of your filesystem disappears, perhaps mid-write! Eek!

I did something like what you're wondering about in the past year or so.
At work, I had two servers with 72G mirrors that needed to get larger.
The only thing I could do (couldn't reformat, no more spare for drives)
was to take 144G drives, and swap them in one at a time, letting the
RAID rebuild on the "replaced" drive, and then when both 144G drives
were in and the RAID rebuilt, rebooting the server into the RAID
controller, and then using the 'extra' space to build a new RAID1
mirror. I then took that new RAID1, created a physical volume on that
new RAID1, and then added it to the Logical Volumes on the server.

So yes, you can do it, but when I did that on two of my blade servers I
made myself a bit nervous. I'm made less nervous since both RAID1
mirrors are on the same drives (as opposed to different or additional
drives) but I still don't like it. I prefer to do things that are easily
understood by the next guy in line.

Option #1 seems like the easiest, and more flexible way to do things.
You can allocate more space from that RAID1 to /home, and even leave
yourself with extra PEs for other volumes in the future, if you felt
like it (allocating it all at once means that at some time in the
future, if you run low on another volume, you'd have to downsize an
existing LV in order to make space for the one that's low.)

AFAICT, there's not many filesystems that have problems getting larger.
XFS, EXT3, MurderFS - they can all be extended safely and quickly (and
in some cases, online!). Either way, you should back up before you
start the work ;)

Adam

> 2. Add the two 300G drives
> set them up in a mirror
> partition it and format it as /home (NOT part of the volset). =20
> Copy the existing /home (from the volset) onto the new /home (the mirrored=
> 300G drive).
> Change the /etc/fdisk from Volgroup00-LogVol07 to /dev/<whatever>.
>
> I think option one is the right approach, but I've never done this before, =
> nor do I know anyone who has. And I don't know what the 'downsides' or got=
> chas' may be. Googling just says what a wonderful thing LVM is but a lot o=
> f it sounds like techiefanboyism. So...what's the right thing to do here?
>
> Thanks!
>
> ---------------------------
>
> $ df -lh
> Filesystem Size Used Avail Use% Mounted on
> /dev/mapper/VolGroup00-LogVol01
> 7.6G 3.5G 3.8G 49% /
> /dev/sda1 99M 25M 69M 27% /boot
> tmpfs 2.0G 0 2.0G 0% /dev/shm
> /dev/mapper/VolGroup00-LogVol07
> 1.9G 1.8G 0 100% /home
> /dev/mapper/VolGroup00-LogVol08
> 1.9G 946M 878M 52% /opt/oracle
> /dev/mapper/VolGroup00-LogVol06
> 961M 20M 892M 3% /tmp
> /dev/mapper/VolGroup00-LogVol05
> 4.8G 628M 3.9G 14% /var
> /dev/mapper/VolGroup00-LogVol02
>
> ---------
> To unsubscribe, send email to <aklug-request@aklug.org>
> with 'unsubscribe' in the message body.
>
>

-- 
Adam
---------
To unsubscribe, send email to <aklug-request@aklug.org>
with 'unsubscribe' in the message body.
Received on Mon Apr 19 20:24:45 2010

This archive was generated by hypermail 2.1.8 : Mon Apr 19 2010 - 20:24:45 AKDT