All of lore.kernel.org
 help / color / mirror / Atom feed
From: David Greaves <david@dgreaves.com>
To: LVM general discussion and development <linux-lvm@redhat.com>
Subject: Re: [linux-lvm] LVM2 seems to chop performance by 33%
Date: Sun, 20 Jun 2004 19:17:58 +0100	[thread overview]
Message-ID: <40D5D4D6.9020307@dgreaves.com> (raw)
In-Reply-To: <1086885029.13087.15.camel@localhost>

Clint Byrum wrote:

>On Thu, 2004-06-10 at 08:34, David Greaves wrote:
>  
>
>>Thanks
>>
>>I'd tried that, but no real change. I started 1t 128k and also tried 
>>64k, 256k :) (oh, and 1k)
>>
>>    
>>
>
>I did some tests a few months ago with bonnie++.. might offer some
>encouragement (please don't post this to slashdot.. ;)
>
>http://spamaps.org/raidtests.php
>
>There's a lot of data there, but if you look at the LVM stuff, you might
>notice that the concurrent performance (having 3 processes hammering the
>disks in different places instead of just one) was quite good when
>compared to flat out RAID5. I'll pay 5% performance for manageability
>any day. :-D
>  
>
Thanks to those that made suggestions.

In the end I used
blockdev --setra 4096 on all my devices (/dev/sda,b,c,d and the /dev/md0 
and the /dev/video_vg/video_lv) and this doubled throughput.

I am reading multi-gigabyte video files so these parameters are not for 
everyone.

No-one ever replied as to why blockdev --setra / --getra is not the same 
as that displayed in lvdisplay
And it's not documented that I can find. There's a comment: "Not used by 
device-mapper." And that means.....?
It's ignored? not implemented yet? Good luck?

# lvdisplay /dev/video_vg/huge_lv
  --- Logical volume ---
  LV Name                /dev/video_vg/huge_lv
  VG Name                video_vg
  LV UUID                3kz7n9-97Rg-2LJw-J9ml-1BBS-jGs0-Onh4NI
  LV Write Access        read/write
  LV Status              available
  # open                 1
  LV Size                312.50 GB
  Current LE             5000
  Segments               1
  Allocation             inherit
  Read ahead sectors     120
  Block device           253:1

# blockdev --getra /dev/video_vg/huge_lv
4096

<sigh> Let this post be there for Google - the modern man-page for 
linux. (if you've got your fingers crossed!)

David

  reply	other threads:[~2004-06-20 18:18 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-06-10 14:25 [linux-lvm] LVM2 seems to chop performance by 33% David Greaves
2004-06-10 15:05 ` Stuart Harper
2004-06-10 15:31   ` Chris Croswhite
2004-06-10 15:34   ` David Greaves
2004-06-10 16:30     ` Clint Byrum
2004-06-20 18:17       ` David Greaves [this message]
2004-06-20 19:53         ` Alasdair G Kergon
2004-06-21  9:55           ` David Greaves
2004-06-14 11:50 ` Miguel Cabeça
2004-06-14 13:24   ` David Greaves

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=40D5D4D6.9020307@dgreaves.com \
    --to=david@dgreaves.com \
    --cc=linux-lvm@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.