Re: [opensuse] Re: [OT] vmware and fake scsi devs

On Dec 5, 2007 1:50 PM, Greg Freemyer <greg.freemyer@xxxxxxxxx> wrote:

On Dec 4, 2007 1:49 PM, Aaron Kulkis <akulkis00@xxxxxxxxxx> wrote:
Chris Worley wrote:
On Dec 4, 2007 10:22 AM, Jc Polanycia <JC.Polanycia@xxxxxxxxxxxx> wrote:
Off topic, as I seldom partition anything (unpartitioned drives
perform best), but, you're setting yourself up for disaster using LVM
(any corruption to the LVM layer is not recoverable... you'll loose
everything... been there done that), and the performance is poor, and
MD RAID5/6 devices can be grown (add more disks).

Chris

Fair enough. I appreciate the input because I haven't run across any
real-world stories about LVM corruption. I have personally encountered
corruption problems with RAID5/6 as well as problems with decreased
performance as a RAID5 structure gets more members added to it.

I saw some RAID6 issues last year, so I use RAID5... but recent tests
have shown MD RAID6 as solid.

"Decreased performance as more members get added to it"? Bull!!! I'm
guessing you have another bottleneck that has led you to this
conclusion.

While the performance increase doesn't scale linearly as disks are
added (some CPU verhead is added with each additional drive), the more
disks, the better the performance. I'm sure there is some Amdahl's
law limit to the increased performance scalability, but I run RAIDS up
to 12 drives, and see performance added w/ each new member.


You're hallucinating. That defies basic information theory.

Your assertion is akin to suggesting that you power your
computers with a perpetual motion machine (despite the
fact that such would violate the 1st, 2nd, and 3rd laws
of thermodynamics).

Single threaded access to a raid array may not be helped by adding
drives. Drive access can end up being sequential and your not really
buying anything.

Multi-threaded storage performance is definitely positively affected
by adding disks to an array.

For multi-threaded, effectively each disk can do N IOPS (IOs per Second.)

So if you have M drives, you can do M*N IOPS.

The trouble with Raid 5 is that it typically requires 4 IOs to update
a single sector.

ie.
Read checksum,
Read original sector, (so you can remove it from the checksum)
write updated sector
write new checksum.

So it ends up being M*N / 4 IOPS.
Greg,

Doesn't that assume a sector/block mismatch? If your sectors and
blocks are aligned (sectors are some multiple of blocks), then no
read-mask-write is necessary.

Even if there is a misalignment, if the amount of data being written
is large, the read-mask-write operation is only at the beginning and
tail ends of the entire operation.

Also, the writes are all in parallel. The above makes it sound like
the writes of updated stripes, and the write of the checksum are
serial... they should all be posted nearly simultaneously (some
serialization introduced by the CPU).


So from a performance perspective on _writes_ you need at least a 4
drive array just to be as fast as a single disk.

Reads OTOH just need to read the sector they want (unless you have a
failed drive).

So _read_ performance is M*N. Or always faster than a single drive.


On a RAID5 you only need M-1 (or M-2 for RAID6) completions of
parallel operations... you can discard the slowest disks results, as
that can be recreated without all the data.

Chris
Greg
--
Greg Freemyer
Litigation Triage Solutions Specialist
http://www.linkedin.com/in/gregfreemyer
First 99 Days Litigation White Paper -
http://www.norcrossgroup.com/forms/whitepapers/99%20Days%20whitepaper.pdf

The Norcross Group
The Intersection of Evidence & Technology
http://www.norcrossgroup.com
--

To unsubscribe, e-mail: opensuse+unsubscribe@xxxxxxxxxxxx
For additional commands, e-mail: opensuse+help@xxxxxxxxxxxx


--
To unsubscribe, e-mail: opensuse+unsubscribe@xxxxxxxxxxxx
For additional commands, e-mail: opensuse+help@xxxxxxxxxxxx

Relevant Pages