Chris Worley wrote:
On Dec 5, 2007 1:50 PM, Greg Freemyer
wrote: On Dec 4, 2007 1:49 PM, Aaron Kulkis
wrote: Chris Worley wrote:
On Dec 4, 2007 10:22 AM, Jc Polanycia
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).
No, they are NOT in parallel. The are issued sequentially. They may overlap (only if you have SCSI, or if all of the disks are on different controllers), but they are not in parallel. You're obviously a CS major, not an engineer. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org