RE: [linux-lvm] LVM performance

[Steven Lembark <lembark@wrkhors.com>]

-- Steve Wray <steve.wray@the.net.nz>

>> From: linux-lvm-admin@sistina.com [mailto:linux-lvm-admin@sistina.com]On
>> Behalf Of Bradley M Alexander
>> On Fri, Nov 23, 2001 at 05:32:07PM +1300, Steve Wray wrote:
>> >
>> > thats dead right; ide can't simultaneously write to the master and
>> > slave on the same controller. Also, the pair of drives uses the
>> > controller circuitry
>> > of the master, so it always pays to make the master the most modern
>> > one.
>>
>> Since both controllers have a drive master and a cd slave, this shouldn't
>> matter, per se.
>
> yeah but I thought I'd mention it, for completeness
> :)

Dependong on the bios, for example, there still could be
contention on the SB chipset for access to the controllers.
Point is that there can be multiple bottlenecks.

>> > > Can anyone give me any ideas as to why the machine gets
>> beaten about so
>> > > much during IO operations and more importantly how can I minimize the
>> > > impact.
>> >
>> > Dunno, if it was because the fs is striped across those drives then
>> > splitting them across controllers would have made it go away.
>>
>> Nothing should be striped across the drives. I have two PVs and made two
>> VGs, one on each drive. The way it works out, the data I am
>> mastering is on
>
> yup you have to tell it to stripe, as I recall. Never used that feature
> tho.

I'm using LVM with several striped volumes. Hardware is Tekram
160MB scsi + pair of 80MB drives. The striping works rather
nicely: sustained I/O is high for large copies and latency is
low for reads. The file system uses a 4KB page w/ the inodes
reduced to a reasonable value (e.g., mkfs.ext2 -b4096 -i10240).

If you are using the default of 1block / page then it can
hammer a system due to 2ndary access and higher write rate.

>> > I've seen no performance problems at all and really thrashed an
>> > LVM-root machine for test purposes while working on a movie. It took
>> > it well, performance-wise. (reliability is another issue; never go
>> > LVM-root... but thats just my 2 cents, YMMV).
>>
>> Yeah, I wasn't brave enough to go all out...And with the problems I was
>> having, I'm glad I made that decision. :)
>
> I think the worst part is the lack of backward compatibility
> at some stages of LVM. With root on LVM it can be a bit dangerous
> to upgrade! Or at least it was...

<broken-record>
This can also be a real pain to fix if something goes wrong. If
the lvm is --prefix-ed to, say, /lvm and the root volume is
on a paritition then you can fix most things w/o having to
play with rescue file systems.
</broken-record>

--
Steven Lembark                               2930 W. Palmer
Workhorse Computing                       Chicago, IL 60647
                                            +1 800 762 1582