RE: [linux-lvm] Apparent performance degradation for each PV with striping

RE: [linux-lvm] Apparent performance degradation for each PV with striping

[S. Michael Denton]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Monday, 19 March 2001 02:07, Jason Walker [SMTP:unseen@sover.net]
wrote:
> 
> I have 2 45gb IBM drives and a 3ware controller for them. I am just
> writing to second this e-mail in saying the controller is
> fantastic. in fact, my frined has the same exact setup as I do
> (he's not bold enough to LVM it...but I am working on that :) I
> have LVM'd the entire thing and have XFS on it all. Anyways, you
> can't go wrong with these cards. (just thought I would put my $.02
> in)
> 
> Jason

I tend to agree.  In general software RAID will bog the system down
and if performance is key, you should take the load off the CPU
whereever possible.  The obvious conclusion with data volumes is to
use a hardware RAID controller, beit SCSI or IDE... I've used both
SCSI raid controllers and the IDE promise raid controller with good
results.  The other thing that may be killing your performance is IO
contention.  Check for other highly-used devices on the same PCI
bus... on PCs there are quite a few points of possible contention.

Just -my- 2 cents :)

> On Mon, 19 Mar 2001 lvm@winux.com wrote:
> 
> 
> > Donald Thompson writes:
> > > I notice during the dd operation that my system CPU state is
> > > 90% or more.  So I think I just answered my own question, I'm
> > > CPU bound. Moving on, is there any known ways to improve my
> > > performance off each PV with this type of hardware setup?
> > > ...
> > > Should I expect that I won't see the performance drop on
> > > individual PV's with striping on SCSI drives? I originally
> > > setup this system with no intentions of it being a high
> > > performance file server, until a few people I work with decided
> > > they wanted to use it for a database machine. So I'm not afraid
> > > to spend a couple grand to get some faster disks in it if thats
> > > the only thing
> > > thats gonna help me.
> > 
> > Hi Donald,
> > 
> > I think what you're seeing is to be expected from vanilla IDE.
> > Not only is it not Linux LVM's fault but Linux LVM can't fix it.
> > IDE controllers are not able to do the things more sophisicated
> > controllers and host adapters do to increase performance in a
> > multi-spindle environment.  Fortunately, there is a solution
> > that's fast, cheap, and reliable.
> > 
> > I suggest that, rather than replacing the drives with
> > expensive SCSI drives and an expensive SCSI host adapter,
> > you buy an Escalade Switch from http://www.3ware.com/ and
> > use your existing drives.
> > 
> > The Escalade is a hybrid controller of sorts.  It presents itself
> > as a SCSI host adapter to the host's PCI bus and as multiple (up
> > to 8) independent IDE controllers to the IDE drives.  It's
> > essentially a cross-bar switch that lets multiple IDE drives act
> > independently of one another.  They use some clever controller
> > software to get a BETTER than 2x boost in read-performance when
> > you mirror drives.
> > 
> > It has the additional advantage of providing RAID for the
> > attached drives. It supports RAID 0, 1, 10, and 5, so you get all
> > those benefits without imposing ANY additional CPU load.  The
> > controller is actually quite a gem and is very reasonably priced.
> >  I've been using them on all of my systems where performance
> > and/or reliability are critical.  
> > 
> > The Escalade driver is supported in the standard 2.2.x and 2.4.x
> > Linux kernels.  
> > 
> > In short, let 3ware's hardware handle the striping/RAID and use
> > Linux LVM to manage the volume.  It's a powerful combination.
> > 
> > Larry
> > 
> > DISCLAIMER:  These statements reflect my personal opinions... bla
> > bla bla. I don't have any affiliation with 3ware or anyone else
> > in this business.  
> > 
> > CLAIMER:  3ware makes good stuff that works very well.
> > It solved my problems and it could solve yours.
> > _______________________________________________
> > linux-lvm mailing list
> > linux-lvm@sistina.com
> > http://lists.sistina.com/mailman/listinfo/linux-lvm
> > 
> 
> -- 
> Jason Walker -- unseen@sover.net, perlgod@hotmail.com
> UIN: 110493687
> AIM: Nightface
> 
> /"\
> \ /     ASCII RIBBON CAMPAIGN
>  X        AGAINST HTML MAIL
> / \
> 			 
> 
> _______________________________________________
> linux-lvm mailing list
> linux-lvm@sistina.com
> http://lists.sistina.com/mailman/listinfo/linux-lvm


Scott Denton
smdenton@bellsouth.net
EFnet Handle: SteelWyng
ICQ UIN: 24149258
AIM Screen Name: SteelWyng

-----BEGIN PGP SIGNATURE-----
Version: PGPfreeware 6.5.3 for non-commercial use <http://www.pgp.com>

iQA/AwUBOrYK0XC+DNfF0nVpEQJSBQCgrSWfAmAtjFod5+F+n7A0vw3sZQAAni/0
wnb49uCl8xeE8DNEcMGxcH5A
=vrnk
-----END PGP SIGNATURE-----

Re: [linux-lvm] Apparent performance degradation for each PV with striping

[Steven Lembark]

> I tend to agree.  In general software RAID will bog the system down
> and if performance is key, you should take the load off the CPU
> whereever possible.  The obvious conclusion with data volumes is to
> use a hardware RAID controller, beit SCSI or IDE... I've used both
> SCSI raid controllers and the IDE promise raid controller with good
> results.  The other thing that may be killing your performance is IO
> contention.  Check for other highly-used devices on the same PCI
> bus... on PCs there are quite a few points of possible contention.
> 
> Just -my- 2 cents :)
> 
> > On Mon, 19 Mar 2001 lvm@winux.com wrote:
> >
> >
> > > Donald Thompson writes:
> > > > I notice during the dd operation that my system CPU state is
> > > > 90% or more.  So I think I just answered my own question, I'm
> > > > CPU bound. Moving on, is there any known ways to improve my
> > > > performance off each PV with this type of hardware setup?
> > > > ...
> > > > Should I expect that I won't see the performance drop on
> > > > individual PV's with striping on SCSI drives? I originally
> > > > setup this system with no intentions of it being a high
> > > > performance file server, until a few people I work with decided
> > > > they wanted to use it for a database machine. So I'm not afraid
> > > > to spend a couple grand to get some faster disks in it if thats
> > > > the only thing
> > > > thats gonna help me.
> > >
> > > Hi Donald,
> > >
> > > I think what you're seeing is to be expected from vanilla IDE.
> > > Not only is it not Linux LVM's fault but Linux LVM can't fix it.
> > > IDE controllers are not able to do the things more sophisicated
> > > controllers and host adapters do to increase performance in a
> > > multi-spindle environment.  Fortunately, there is a solution
> > > that's fast, cheap, and reliable.
> > >
> > > I suggest that, rather than replacing the drives with
> > > expensive SCSI drives and an expensive SCSI host adapter,
> > > you buy an Escalade Switch from http://www.3ware.com/ and
> > > use your existing drives.
> > >
> > > The Escalade is a hybrid controller of sorts.  It presents itself
> > > as a SCSI host adapter to the host's PCI bus and as multiple (up
> > > to 8) independent IDE controllers to the IDE drives.  It's
> > > essentially a cross-bar switch that lets multiple IDE drives act
> > > independently of one another.  They use some clever controller
> > > software to get a BETTER than 2x boost in read-performance when
> > > you mirror drives.
> > >
> > > It has the additional advantage of providing RAID for the
> > > attached drives. It supports RAID 0, 1, 10, and 5, so you get all
> > > those benefits without imposing ANY additional CPU load.  The
> > > controller is actually quite a gem and is very reasonably priced.
> > >  I've been using them on all of my systems where performance
> > > and/or reliability are critical.
> > >
> > > The Escalade driver is supported in the standard 2.2.x and 2.4.x
> > > Linux kernels.
> > >
> > > In short, let 3ware's hardware handle the striping/RAID and use
> > > Linux LVM to manage the volume.  It's a powerful combination.

Escalade is a nice idea, but still runs afoul of the interrupt
& bus design of PC's.  for high-i/o applications "PC" hardware
doesn't work all that well.  main problem here is delivering the
raw datat to an Esc. controller through the existing PC.  the
add'l cpu load in this case comes from the bottom-half of drivers
on heavily loaded cards that spend too much time waiting for 
access to the shared card.  

these are a distinct improvement over stock IDE or software RAID
but don't expect them to suddenly turn your PC into a SparcServer
or K400.

note on the benchmark:  you can push the CPU to 100% w/ the dd
of=/dev/null
trick because there isn't any latency on the destination side.  with
a normal disk the cpu has time between writes due to bus & hardware
access.  if you want to bring the system to its knees try:

	dd if=/dev/zero of=/dev/null bs=8k;

lacking any hardware or bus latency, this hits 100% immediately.

using /dev/null and /dev/zero for i/o is useful but you have to 
take the results with a big chunk of salt.  rather than watch the
CPU idle % you might get better results from procinfo -n10 -D and
watching the interrupt vs. i/o rates.  tickle hdparm until the 
int / blocks is low (there are some useful config options floating
around, i can look them up if you can't find them).

-- 
 Steven Lembark                                   2930 W. Palmer St.
                                                 Chicago, IL  60647
 lembark@wrkhors.com                                   800-762-1582

Re: [linux-lvm] Apparent performance degradation for each PV with striping

[Russell Coker]

On Monday 19 March 2001 14:44, Steven Lembark wrote:
> Escalade is a nice idea, but still runs afoul of the interrupt
> & bus design of PC's.  for high-i/o applications "PC" hardware
> doesn't work all that well.  main problem here is delivering the
> raw datat to an Esc. controller through the existing PC.  the
> add'l cpu load in this case comes from the bottom-half of drivers
> on heavily loaded cards that spend too much time waiting for
> access to the shared card.
>
> these are a distinct improvement over stock IDE or software RAID
> but don't expect them to suddenly turn your PC into a SparcServer
> or K400.

What is a K400?

Every test that I run shows SPARC machines running slower than desktop 
machines with IA32 CPUs.  My Athlon-800 machine has more memory bandwidth 
than an E450 according to the industry standard "streams" benchmark and 
according to a little memory benchmark I wrote.  Also a single IBM 46G ATA 
drive in my Athlon outperforms A1000 arrays in E450 class hardware.

> note on the benchmark:  you can push the CPU to 100% w/ the dd
> of=/dev/null

What type of hard drive and what type of CPU?

In terms of using CPU power through IO my record was >80% of the power of my 
Athlon800 when doing "cat /dev/zero > file", then I fixed cat to use 4K 
buffers instead of 1K and it used significantly less CPU power.

I suspect that a large part of this was due to inefficiencies in ReiserFS in 
this regard.  It's still on my to-do list to do some more comprehensive tests 
of this issue with other file systems and with raw devices.

-- 
http://www.coker.com.au/bonnie++/     Bonnie++ hard drive benchmark
http://www.coker.com.au/postal/       Postal SMTP/POP benchmark
http://www.coker.com.au/projects.html Projects I am working on
http://www.coker.com.au/~russell/     My home page

Re: [linux-lvm] Apparent performance degradation for each PV with striping

[Ragnar Kjørstad]

On Thu, Mar 22, 2001 at 09:54:11AM +0100, Russell Coker wrote:
> On Monday 19 March 2001 14:44, Steven Lembark wrote:
> > Escalade is a nice idea, but still runs afoul of the interrupt
> > & bus design of PC's.  for high-i/o applications "PC" hardware
> > doesn't work all that well.  main problem here is delivering the
> > raw datat to an Esc. controller through the existing PC.  the
> > add'l cpu load in this case comes from the bottom-half of drivers
> > on heavily loaded cards that spend too much time waiting for
> > access to the shared card.
> >
> > these are a distinct improvement over stock IDE or software RAID
> > but don't expect them to suddenly turn your PC into a SparcServer
> > or K400.
> 
> What is a K400?
> 
> Every test that I run shows SPARC machines running slower than desktop 
> machines with IA32 CPUs.  My Athlon-800 machine has more memory bandwidth 
> than an E450 according to the industry standard "streams" benchmark and 
> according to a little memory benchmark I wrote.  Also a single IBM 46G ATA 
> drive in my Athlon outperforms A1000 arrays in E450 class hardware.

I second this.
Every test we've run show that x86 linux boxes kick sparc but. :-)

x86 with scsi-scsi RAID controllers we se performance 5-6 times that of
E450s with A1000 RAID. Linux has a reputation for not matching other
systems on NFS performance, but our tests show x86 linux beeing faster than
both x86 freeBSD and SPARC Solaris (both client and server-side)

However: the escalade RAID-controller doesn't have any write-back cache,
does it? So performance actually be worse than on single disk systems
(in some situations - see thread on reiserfs-list), and won't even
compare to a real scsi-scsi or fc-scsi RAID-system.

Anyway - we're getting off-topic awfully fast here; please send
followups directly pr mail and remove lvm-list.



-- 
Ragnar Kj�rstad
Big Storage

Re: [linux-lvm] Apparent performance degradation for each PV with striping

[zoo1]

[-- Attachment #1: Type: text/plain, Size: 1978 bytes --]

On Thu, Mar 22, 2001 at 09:54:11AM +0100, Russell Coker wrote:

>What is a K400?

possibly he means a HP PA-RISC 9000 K4xx class machine, but i can't
speak for him.

the K-class is now quite old; i don't think there was anything industry
standard or nonproprietary in them other than their SCSI busses, unless
you count the network interfaces or the serial ports - they used HP
proprietary bus architectures throughout. their CPUs are something to be
seen; imagine a 10cm-by-12cm circuitboard surrounded by about 10 kg of
sheet-metal copper plate acting as a heatsink. clock speed? up to about
200 MHz, IIRC. i've no idea what their bus throughput might be. if they
use a crossbar, possibly high, but i just don't know if they do.

>Every test that I run shows SPARC machines running slower than desktop 
>machines with IA32 CPUs.  My Athlon-800 machine has more memory bandwidth 
>than an E450 according to the industry standard "streams" benchmark and 
>according to a little memory benchmark I wrote.  

try benchmarking the E450's bus. load it with a full complement of disk
backplanes and two or three gigabit ethernets and stress test that; see
if you can find any IA32 machine to even come close. Sun has never had
fast CPU's, but they're I/O speed demons, always have been.

>Also a single IBM 46G ATA 
>drive in my Athlon outperforms A1000 arrays in E450 class hardware.

couldn't speak about those, i've no experience with the A1000. for
serious storage, you'd naturally use 10K RPM drives in RAID
configurations, and i'd be extremely surprised if the bus you connect
the drives up with had more impact than the rotational speed and seek
time; unless you're bottlenecking the bus, in which case you've made a
design error there.

-- 
   PGP/GnuPG key (ID 1024D/BFE0D6D0) available from keyservers everywhere

       "Everything I am today, I owe to people whom it is now too late
                                   to punish."

[-- Attachment #2: Type: application/pgp-signature, Size: 232 bytes --]

Re: [linux-lvm] Apparent performance degradation for each PV with striping

[Russell Coker]

On Monday 19 March 2001 14:34, S. Michael Denton wrote:
> I tend to agree.  In general software RAID will bog the system down
> and if performance is key, you should take the load off the CPU
> whereever possible.  The obvious conclusion with data volumes is to
> use a hardware RAID controller, beit SCSI or IDE... I've used both
> SCSI raid controllers and the IDE promise raid controller with good
> results.  The other thing that may be killing your performance is IO
> contention.  Check for other highly-used devices on the same PCI
> bus... on PCs there are quite a few points of possible contention.

That really depends on the type of card.  There are many hardware RAID 
devices out there that have significant limits on performance (they give less 
performance from an array of 10000rpm Ultra2-SCSI drives than you expect from 
a single ATA drive).

Hardware RAID controllers that have a CPU that is less than 100MHz in speed, 
or that don't have battery backed cache for write-back caching tend to 
deliver less performance than you hope for.

-- 
http://www.coker.com.au/bonnie++/     Bonnie++ hard drive benchmark
http://www.coker.com.au/postal/       Postal SMTP/POP benchmark
http://www.coker.com.au/projects.html Projects I am working on
http://www.coker.com.au/~russell/     My home page

[linux-lvm] Apparent performance degradation for each PV with striping

[Donald Thompson]

I started playing with iostat tonight and saw a few things I didn't
really expect to see.

I've got a volume group consisting of 4 82 gig drives. All 4 are IDE
drives.
Reading directly from the raw device, a PV in this case, with something
like

dd if=/dev/ide/host0/bus0/target0/lun0/disc of=/dev/null

gave me around 5500 blocks read per second.
Reading from a unstriped LV on a single PV gives me around
4500 blocks read per second, which I felt was reasonable. When I create
a LV striped across all four, my blocks read per second drops to around
1100
per hard drive, giving me a total of about 4400 reads per second for
that LV.
2200 reads per second if I striped it across 2 PV's. Timing how long it
took
to finish a dd for the different types of LV's I made pretty much
confirmed what
iostat was saying. It always took me 45 seconds, give or take a second,
to
read a 100 megabyte LV. So it appears striping is useless for me,
atleast with this
hardware setup.

I notice during the dd operation that my system CPU state is 90% or
more.
So I think I just answered my own question, I'm CPU bound. Moving on,
is there any known ways to improve my performance off each PV with this
type of
hardware setup? I usually create an LV with...

lvcreate -i4 -I4 -L somesize vgname -n lvname

Should I expect that I won't see the performance drop on individual PV's
with striping
on SCSI drives? I originally setup this system with no intentions of it
being a high performance
file server, until a few people I work with decided they wanted to use
it for a database machine.
So I'm not afraid to spend a couple grand to get some faster disks in it
if thats the only thing
thats gonna help me.

My system:

Linux 2.4.2
Libc 2.1.3
Debian Potato
LVM 0.9.1_beta6 utilities and patch.
ATA 100 IDE interfaces on MB
idebus set to 66 in /etc/lilo.conf
CPU is Athlon 1000mhz thunderbird
256 megs of RAM

-Don

Re: [linux-lvm] Apparent performance degradation for each PV with striping

[Eric M. Hopper]

[-- Attachment #1: Type: text/plain, Size: 985 bytes --]

On Sun, Mar 18, 2001 at 10:11:29PM -0700, Donald Thompson wrote:
> I started playing with iostat tonight and saw a few things I didn't
> really expect to see.
> 
> I've got a volume group consisting of 4 82 gig drives. All 4 are IDE
> drives.  Reading directly from the raw device, a PV in this case, with
> something like
> 
> dd if=/dev/ide/host0/bus0/target0/lun0/disc of=/dev/null

	Have you played with hdparm to try to tune the way the kernel
talks to your IDE drives?

	That may be the reason for being CPU bound.  The kernel tends to
default to the slowest possible method because there are a lot of bad
IDE controllers and drives out there that will trash your data if you
try to talk to them in a way they aren't expecting.

Have fun (if at all possible),
-- 
The best we can hope for concerning the people at large is that they
be properly armed.  -- Alexander Hamilton
-- Eric Hopper (hopper@omnifarious.mn.org http://www.omnifarious.org/~hopper) --

[-- Attachment #2: Type: application/pgp-signature, Size: 232 bytes --]

Re: [linux-lvm] Apparent performance degradation for each PV with striping

[Russell Coker]

On Monday 19 March 2001 06:20, Eric M. Hopper wrote:
> 	Have you played with hdparm to try to tune the way the kernel
> talks to your IDE drives?
>
> 	That may be the reason for being CPU bound.  The kernel tends to
> default to the slowest possible method because there are a lot of bad
> IDE controllers and drives out there that will trash your data if you
> try to talk to them in a way they aren't expecting.
>
> Have fun (if at all possible),

The 2.4.x kernels will turn on DMA and multi-mode at boot time if you choose 
the appropriate options in the kernel config.  I generally compile my kernels 
that way so they use the available features in the hardware without the need 
to bother with hdparm.

-- 
http://www.coker.com.au/bonnie++/     Bonnie++ hard drive benchmark
http://www.coker.com.au/postal/       Postal SMTP/POP benchmark
http://www.coker.com.au/projects.html Projects I am working on
http://www.coker.com.au/~russell/     My home page

[linux-lvm] Apparent performance degradation for each PV with striping

[lvm]

Donald Thompson writes:
> I notice during the dd operation that my system CPU state is 90% or
> more.  So I think I just answered my own question, I'm CPU bound.
> Moving on, is there any known ways to improve my performance off
> each PV with this type of hardware setup?
> ...
> Should I expect that I won't see the performance drop on individual PV's
> with striping on SCSI drives? I originally setup this system with no
> intentions of it being a high performance file server, until a few
> people I work with decided they wanted to use it for a database machine.
> So I'm not afraid to spend a couple grand to get some faster disks in it
> if thats the only thing
> thats gonna help me.

Hi Donald,

I think what you're seeing is to be expected from vanilla IDE.
Not only is it not Linux LVM's fault but Linux LVM can't fix it.
IDE controllers are not able to do the things more sophisicated
controllers and host adapters do to increase performance in a
multi-spindle environment.  Fortunately, there is a solution that's
fast, cheap, and reliable.

I suggest that, rather than replacing the drives with
expensive SCSI drives and an expensive SCSI host adapter,
you buy an Escalade Switch from http://www.3ware.com/ and
use your existing drives.

The Escalade is a hybrid controller of sorts.  It presents itself as a
SCSI host adapter to the host's PCI bus and as multiple (up to 8)
independent IDE controllers to the IDE drives.  It's essentially a
cross-bar switch that lets multiple IDE drives act independently of
one another.  They use some clever controller software to get a BETTER
than 2x boost in read-performance when you mirror drives.

It has the additional advantage of providing RAID for the attached drives.
It supports RAID 0, 1, 10, and 5, so you get all those benefits
without imposing ANY additional CPU load.  The controller is actually
quite a gem and is very reasonably priced.  I've been using them on
all of my systems where performance and/or reliability are critical.

The Escalade driver is supported in the standard 2.2.x and 2.4.x Linux kernels.

In short, let 3ware's hardware handle the striping/RAID and use Linux LVM
to manage the volume.  It's a powerful combination.

Larry

DISCLAIMER:  These statements reflect my personal opinions... bla bla bla.
I don't have any affiliation with 3ware or anyone else in this business.

CLAIMER:  3ware makes good stuff that works very well.
It solved my problems and it could solve yours.

Re: [linux-lvm] Apparent performance degradation for each PV with striping

[Donald Thompson]

Actually, I've learned a lot from Eric's comments. After looking
into hdparm and a couple other things, it looks like the kernel settings
as well as hdparm settings are set to about the worst possible (ie. safest)
I could have. Probably most importantly, they aren't using DMA, and
I'll need to recompile the kernel to get it to do so.

I actually was thinking seriously about getting a 3ware card when I
started this machine, but I wussed out and just went with the two onboard
IDE interfaces. Its definately a cheaper option than replacing or adding
SCSI drives to the system.

-Don

lvm@winux.com wrote:

> Donald Thompson writes:
> > I notice during the dd operation that my system CPU state is 90% or
> > more.  So I think I just answered my own question, I'm CPU bound.
> > Moving on, is there any known ways to improve my performance off
> > each PV with this type of hardware setup?
> > ...
> > Should I expect that I won't see the performance drop on individual PV's
> > with striping on SCSI drives? I originally setup this system with no
> > intentions of it being a high performance file server, until a few
> > people I work with decided they wanted to use it for a database machine.
> > So I'm not afraid to spend a couple grand to get some faster disks in it
> > if thats the only thing
> > thats gonna help me.
>
> Hi Donald,
>
> I think what you're seeing is to be expected from vanilla IDE.
> Not only is it not Linux LVM's fault but Linux LVM can't fix it.
> IDE controllers are not able to do the things more sophisicated
> controllers and host adapters do to increase performance in a
> multi-spindle environment.  Fortunately, there is a solution that's
> fast, cheap, and reliable.
>
> I suggest that, rather than replacing the drives with
> expensive SCSI drives and an expensive SCSI host adapter,
> you buy an Escalade Switch from http://www.3ware.com/ and
> use your existing drives.
>
> The Escalade is a hybrid controller of sorts.  It presents itself as a
> SCSI host adapter to the host's PCI bus and as multiple (up to 8)
> independent IDE controllers to the IDE drives.  It's essentially a
> cross-bar switch that lets multiple IDE drives act independently of
> one another.  They use some clever controller software to get a BETTER
> than 2x boost in read-performance when you mirror drives.
>
> It has the additional advantage of providing RAID for the attached drives.
> It supports RAID 0, 1, 10, and 5, so you get all those benefits
> without imposing ANY additional CPU load.  The controller is actually
> quite a gem and is very reasonably priced.  I've been using them on
> all of my systems where performance and/or reliability are critical.
>
> The Escalade driver is supported in the standard 2.2.x and 2.4.x Linux kernels.
>
> In short, let 3ware's hardware handle the striping/RAID and use Linux LVM
> to manage the volume.  It's a powerful combination.
>
> Larry
>
> DISCLAIMER:  These statements reflect my personal opinions... bla bla bla.
> I don't have any affiliation with 3ware or anyone else in this business.
>
> CLAIMER:  3ware makes good stuff that works very well.
> It solved my problems and it could solve yours.
> _______________________________________________
> linux-lvm mailing list
> linux-lvm@sistina.com
> http://lists.sistina.com/mailman/listinfo/linux-lvm

Re: [linux-lvm] Apparent performance degradation for each PV with striping

[Joe Thornber]

On Mon, Mar 19, 2001 at 12:05:36AM -0700, Donald Thompson wrote:
> I actually was thinking seriously about getting a 3ware card when I
> started this machine, but I wussed out and just went with the two onboard
> IDE interfaces. Its definately a cheaper option than replacing or adding
> SCSI drives to the system.

I did some striping tests at the weekend with a pair of IDE disks, I
managed to get 56 M/s read and 28M/s write (according to bonnie++).
These numbers are twice the performance of the slowest of the two IDE
drives, which is good.

- Joe

Re: [linux-lvm] Apparent performance degradation for each PV with striping

[Jason Walker]

I have 2 45gb IBM drives and a 3ware controller for them. I am just writing
to second this e-mail in saying the controller is fantastic. in fact, my
frined has the same exact setup as I do (he's not bold enough to LVM
it...but I am working on that :) I have LVM'd the entire thing and have XFS
on it all. Anyways, you can't go wrong with these cards. (just thought I
would put my $.02 in)

Jason

On Mon, 19 Mar 2001 lvm@winux.com wrote:


> Donald Thompson writes:
> > I notice during the dd operation that my system CPU state is 90% or
> > more.  So I think I just answered my own question, I'm CPU bound.
> > Moving on, is there any known ways to improve my performance off
> > each PV with this type of hardware setup?
> > ...
> > Should I expect that I won't see the performance drop on individual PV's
> > with striping on SCSI drives? I originally setup this system with no
> > intentions of it being a high performance file server, until a few
> > people I work with decided they wanted to use it for a database machine.
> > So I'm not afraid to spend a couple grand to get some faster disks in it
> > if thats the only thing
> > thats gonna help me.
> 
> Hi Donald,
> 
> I think what you're seeing is to be expected from vanilla IDE.
> Not only is it not Linux LVM's fault but Linux LVM can't fix it.
> IDE controllers are not able to do the things more sophisicated
> controllers and host adapters do to increase performance in a
> multi-spindle environment.  Fortunately, there is a solution that's
> fast, cheap, and reliable.
> 
> I suggest that, rather than replacing the drives with
> expensive SCSI drives and an expensive SCSI host adapter,
> you buy an Escalade Switch from http://www.3ware.com/ and
> use your existing drives.
> 
> The Escalade is a hybrid controller of sorts.  It presents itself as a
> SCSI host adapter to the host's PCI bus and as multiple (up to 8)
> independent IDE controllers to the IDE drives.  It's essentially a
> cross-bar switch that lets multiple IDE drives act independently of
> one another.  They use some clever controller software to get a BETTER
> than 2x boost in read-performance when you mirror drives.
> 
> It has the additional advantage of providing RAID for the attached drives.
> It supports RAID 0, 1, 10, and 5, so you get all those benefits
> without imposing ANY additional CPU load.  The controller is actually
> quite a gem and is very reasonably priced.  I've been using them on
> all of my systems where performance and/or reliability are critical.
> 
> The Escalade driver is supported in the standard 2.2.x and 2.4.x Linux kernels.
> 
> In short, let 3ware's hardware handle the striping/RAID and use Linux LVM
> to manage the volume.  It's a powerful combination.
> 
> Larry
> 
> DISCLAIMER:  These statements reflect my personal opinions... bla bla bla.
> I don't have any affiliation with 3ware or anyone else in this business.
> 
> CLAIMER:  3ware makes good stuff that works very well.
> It solved my problems and it could solve yours.
> _______________________________________________
> linux-lvm mailing list
> linux-lvm@sistina.com
> http://lists.sistina.com/mailman/listinfo/linux-lvm
> 

-- 
Jason Walker -- unseen@sover.net, perlgod@hotmail.com
UIN: 110493687
AIM: Nightface

/"\
\ /     ASCII RIBBON CAMPAIGN
 X        AGAINST HTML MAIL
/ \
			 

Re: [linux-lvm] Apparent performance degradation for each PV with striping

[Oleg Volkov]

Donald Thompson wrote:

> dd if=/dev/ide/host0/bus0/target0/lun0/disc of=/dev/null
> gave me around 5500 blocks read per second.
>
> lvcreate -i4 -I4 -L somesize vgname -n lvname
>
> My system:
>
> Linux 2.4.2
> Libc 2.1.3
> Debian Potato
> LVM 0.9.1_beta6 utilities and patch.
> ATA 100 IDE interfaces on MB
> idebus set to 66 in /etc/lilo.conf
> CPU is Athlon 1000mhz thunderbird
> 256 megs of RAM
>
> -Don
>
> _______________________________________________
> linux-lvm mailing list
> linux-lvm@sistina.com
> http://lists.sistina.com/mailman/listinfo/linux-lvm

80G disks may be IBM or Maxtor disks ( right ? )
I had experience with IBM disks. A good stripe
size for them is 64k. I don't know about Maxtor disks
but you can play with stripe size around 64k also.

Basically 64k is a DMA buffer size and should be good.

So try to use -I64 not -I4.


--
Volkov Oleg
BitBand Technologies Ltd.
http://www.bitband.com