[linux-lvm] LVM vs. md: Benefits in RAID0?

[linux-lvm] LVM vs. md: Benefits in RAID0?

[Jason Tackaberry]

I am about to be deploying a new server whose purpose is to replace an
existing, aging system.  The new server has 2 18GB drives.  Once I
migrate the user data to the new server, I can reclaim a practically
brand new 18GB disk in the old server, bringing the total raw capacity
to 18x3 GB.

I installed RH7.1 and was happy to see how easy it was to setup
mirroring using the md driver.  My plan was to setup 9GB on each disk in
a RAID1 config, and then stripe the remaining 9GB on each disk for user
data in /home.  Then, when I migrated the user data from the old server,
I could add the 18GB into /home to give me 36GB for user data.  (I want
redundancy for the system partitions because as this is a mail server, I
do not want the flow of mail to be interrupted during a disk failure.
For user data I want to go for raw storage, since I will take full
backups nightly.)

In planning the migration, I discovered that md does not allow you to
grow.  Well, no problem, I know LVM supports this, so I setup LVM to
stripe the 2 9GB partitions together.  Then, I dropped a 3rd disk in to
test the procedure of adding a new disk to the stripe set.  I
unfortunately then discovered LVM won't let you extend a RAID0 volume,
but this is supposedly a planned feature for post-1.0.

I assume the only way to proceed is to use linear concatenation.  This
lets me extend the volume, but then I don't get the performance gain I'd
see with RAID0.  But, as I understand the LVM, its advantage is that it
lets you resize volumes.  Since you can't currently do this in RAID0,
does the LVM offer any benefits over md in this situation?

Thanks,
Jason.

--
Academic Computing Support Specialist         Assistant Section Editor
Algoma University College                     http://linux.com/develop
Sault Ste. Marie, Ontario                 
705-949-2301 x330                                   Personal Home Page
http://www.auc.ca                                     http://sault.org

Re: [linux-lvm] LVM vs. md: Benefits in RAID0?

[José Luis Domingo López]

On Tuesday, 24 July 2001, at 15:13:19 -0400,
Jason Tackaberry wrote:

> I am about to be deploying a new server whose purpose is to replace an
> existing, aging system.  The new server has 2 18GB drives.  Once I
> migrate the user data to the new server, I can reclaim a practically
> [...]
>
The quick and dirty hack to get resizable RAIDed storage devices is:

a) Layer LVM on top of (hard/soft) RAID
b) Layer sotfware RAID on top of software LVM

My tests with _crappy_ hardware show better performance with setup a). It
has the added advantage of being able to use hardware RAID, and avoid
some layering overhead on the operating system side (there are quite
inexpensive SCSI hardware RAID for IDE and SCSI buses out there).

With setup a), you should create one or more RAID devices (depending on
type and information to be stored) and then, create a VG from each RAID
device. For example, a 3-disk software RAID-5 consisting of 3 10 GB
partitions gives you a /dev/md0 20 GB large.

Make a pvcreate /dev/md0, then a vgcreate Group00 /dev/md0 and define LV
from this VG (lvcreate -n Group00 -L 5G Volume00). This LV holds your data
and avoids loosing them upon a 1-disk failure (RAID-5), and lets you
hot-resize the LV (if the filesystem allows it).

Greetings.

--
Jos� Luis Domingo L�pez
Linux Registered User #189436     Debian GNU/Linux Potato (P166 64 MB RAM)
 
jdomingo EN internautas PUNTO org  => � Spam ? Atente a las consecuencias
jdomingo AT internautas DOT   org  => Spam at your own risk

Re: [linux-lvm] LVM vs. md: Benefits in RAID0?

[Jason Tackaberry]

Hi José, thanks for your reply.  I have a few questions:

On 24 Jul 2001 22:46:56 +0000, José Luis Domingo López wrote:
> The quick and dirty hack to get resizable RAIDed storage devices is:
> 
> a) Layer LVM on top of (hard/soft) RAID

The problem I see with this is that if you extend the volume group by
adding a new partition, the new partition must be linearly concatenated
and so it won't be part of the stripe set.  So while you can technically
extend this configuration, you're not truly resizing the RAID device.
Suppose you start off with an md stripe set with sda1 and sdb1, and then
later on you want to add sdc1, you get something like this:

<lame ASCII art>
+----------------------------+
|         logical_vol01      |
+----------------------------+
|         volume_group01     |
+-------------------+--------+
|     md0 RAID0     |        |
+-------------------+  sdc1  |
|   sda1   |  sdb1  |        |
+----------+--------+--------+
</lame ASCII art>

So yes, you can extend your logical volume, but you're not extending
your stripe set.  I guess this has the advantage over linear
concatenation in that at least for sda1 and sdb1 you'll get the
performance benefit.

> b) Layer sotfware RAID on top of software LVM

I'm just not sure how this would work?  You can't extend md devices, as
far as I know.  So you can extend the underlying logical volume, but
then from the RAID layer on top, it just sees one device, so it's not
really RAID at all.  Can you clarify on this one?

Cheers,
Jason.

Re: [linux-lvm] LVM vs. md: Benefits in RAID0?

[José Luis Domingo López]

On Tuesday, 24 July 2001, at 19:32:35 -0400,
Jason Tackaberry wrote:

> Hi Jos�, thanks for your reply.  I have a few questions:
> 
> On 24 Jul 2001 22:46:56 +0000, Jos� Luis Domingo L�pez wrote:
> > The quick and dirty hack to get resizable RAIDed storage devices is:
> > 
> > a) Layer LVM on top of (hard/soft) RAID
> 
> The problem I see with this is that if you extend the volume group by
> adding a new partition, the new partition must be linearly concatenated
> and so it won't be part of the stripe set.  So while you can technically
> extend this configuration, you're not truly resizing the RAID device.
> Suppose you start off with an md stripe set with sda1 and sdb1, and then
> later on you want to add sdc1, you get something like this:
> 
What I was thinking about was an underlying RAID0 device with a size
greater than the largest LV size you will ever need. I searched through
linux-raid archives and I found no reference about whether "extending"
stripped RAIDs (0 and 5) is something possible or feasable to do.

My idea was: take 3 40 GB disks, get a 80 GB RAID 0 and create LV and
filesystems on demand. Maybe you don't need to store 80 GB worth of data
by now, so you have some GB left just in case. Should your dataset ever
grows too much, lvextend to a maximun on 80 GB (minus space for the rest
of the LV created).

If extending stripped RAIDs is not possible, adding a single drive to the
existing VG can impose a bottleneck on R/W speed, so maybe is a matter of
generating another stripped RAID similar to the old one, and add it to the
VG with a simple vgextend. In this situation you have to be very careful
about placing disks and making backups if you want to retain high R/W
performance and/or protection on disk failures (for certain RAID levels).

That is, borrowing your "lame ASCII art" ;-), you'll get:

+--------------------------------+
|         logical_vol01          |
+--------------------------------+----+
|         volume_group01              |
+-------------------+-----------------+
|     md0 RAID0     |   md1 RAID 0    |
+-------------------+--------+--------+
|   sda1   |  sdb1  |  sdc1  |  sdd1  |
+----------+--------+--------+--------+


> > b) Layer sotfware RAID on top of software LVM
> 
> I'm just not sure how this would work?  You can't extend md devices, as
> far as I know.  So you can extend the underlying logical volume, but
> then from the RAID layer on top, it just sees one device, so it's not
> really RAID at all.  Can you clarify on this one?
> 
Think about a RAID device made of LVs: you configure /etc/raidtab, write
RAID superblocks with mkraid and create a filesystem over md0. Should you
need a larger md0 device, put RAID offline, enlarge the corresponding LV
and rewrite RAID superblocks on these LV with mkraid -f.

As far as I know, mkraid just generates RAID superblocks, without touching
real data (except when you change RAID type :). After mkraid -f, cat
/proc/mdstat shows the new size of the RAID device, and you are only a
filesystem resize from a larger RAID over LVM.

All of these tried on a test machine, just for the fun of it. I don't have
neither the hardware nor the time to test this, with "real" hardware and
"real" data. I hope to have both time and hardware to play with on August,
when people is on vacation and business is quite low.

Greetings.

-- 
Jos� Luis Domingo L�pez
Linux Registered User #189436     Debian GNU/Linux Potato (P166 64 MB RAM)
 
jdomingo EN internautas PUNTO org  => � Spam ? Atente a las consecuencias
jdomingo AT internautas DOT   org  => Spam at your own risk

RE: [linux-lvm] LVM vs. md: Benefits in RAID0?

[Gonyou, Austin]

What I see in my mind is this should work the same way veritas or hardware
raid should work. Adding a new partition to a stripe set shouldn't get
concatenated. The data should get re-striped to include the new disk, and as
time goes on, data will be then evened out to include this new partition and
stripe proplerly. Doing this approach preserves the stripe, at a small cost
of CPU during the slow re-stripe. The alternative is to have quick
re-restripes occurr, and to have XX% of cpu allocated to making that happen.
That way you can say, I want to give 98% of my cpu to the re-stripe
operation, but I know that my system will be unuseable during that
time(mostly), but it will take less time than say several hours where
re-striping would occurr slowly as data or accesses occurr and bits are
remapped. This of course means that you need a small amount of freespace not
allocated at the time of stripe creation. Adaptec and AMI accomplishes this
by setting about 4MB per volume in the striped set or raid x, as unused
automatically. That way, even if you have a raid set which is full of data
and perhaps <1% left, you still have these "swap regions" for use during
dynamic reallocation/restriping. This is what I see LVM being able to do in
the future, since it is already done in software from other vendors anyway. 

-- 
Austin Gonyou
Systems Architect, CCNA
Coremetrics, Inc.
Phone: 512-796-9023
email: austin@coremetrics.com 

> -----Original Message-----
> From: Jason Tackaberry [mailto:tack@linux.com]
> Sent: Tuesday, July 24, 2001 6:33 PM
> To: linux-lvm@sistina.com
> Subject: Re: [linux-lvm] LVM vs. md: Benefits in RAID0?
> 
> 
> Hi José, thanks for your reply.  I have a few questions:
> 
> On 24 Jul 2001 22:46:56 +0000, José Luis Domingo López wrote:
> > The quick and dirty hack to get resizable RAIDed storage devices is:
> > 
> > a) Layer LVM on top of (hard/soft) RAID
> 
> The problem I see with this is that if you extend the volume group by
> adding a new partition, the new partition must be linearly 
> concatenated
> and so it won't be part of the stripe set.  So while you can 
> technically
> extend this configuration, you're not truly resizing the RAID device.
> Suppose you start off with an md stripe set with sda1 and 
> sdb1, and then
> later on you want to add sdc1, you get something like this:
> 
> <lame ASCII art>
> +----------------------------+
> |         logical_vol01      |
> +----------------------------+
> |         volume_group01     |
> +-------------------+--------+
> |     md0 RAID0     |        |
> +-------------------+  sdc1  |
> |   sda1   |  sdb1  |        |
> +----------+--------+--------+
> </lame ASCII art>
> 
> So yes, you can extend your logical volume, but you're not extending
> your stripe set.  I guess this has the advantage over linear
> concatenation in that at least for sda1 and sdb1 you'll get the
> performance benefit.
> 
> > b) Layer sotfware RAID on top of software LVM
> 
> I'm just not sure how this would work?  You can't extend md 
> devices, as
> far as I know.  So you can extend the underlying logical volume, but
> then from the RAID layer on top, it just sees one device, so it's not
> really RAID at all.  Can you clarify on this one?
> 
> Cheers,
> Jason.
> 
> _______________________________________________
> linux-lvm mailing list
> linux-lvm@sistina.com
> http://lists.sistina.com/mailman/listinfo/linux-lvm
> read the LVM HOW-TO at http://www.sistina.com/lvm/Pages/howto.html
>