All of lore.kernel.org
 help / color / mirror / Atom feed
From: Urs Thuermann <urs@isnogud.escape.de>
To: linux-lvm@sistina.com
Subject: Re: [linux-lvm] LVM and *bad* performance (no striping)
Date: 26 May 2001 13:17:26 +0200	[thread overview]
Message-ID: <m2ofsguzp5.fsf@isnogud.escape.de> (raw)
In-Reply-To: <20010515131357.D524@tykepenguin.com>; from Patrick Caulfield on Tue, 15 May 2001 13:13:57 +0100

Patrick Caulfield <caulfield@sistina.com> writes:

> I think one problem is that your "benchmarks" are not very realistic. In 
> real world use the overhead of LVM is very small. I would respectfully suggest
> that you try something like bonnie++ before getting too worried about the 
> performance of LVM on your machine - unless you spend most of your day doing
> "dd" to your disks :-)

The reason I tested dd on the partition and on the LV is that I
thought when the performance of the block device is bad (like it is on
my LV) this will have an impact on a mounted file system on that LV.
If also thought, the performance of dd if=/dev/vg0/test will be
approximately equal to dd if=/mnt/foo od md5sum foo where foo is large
file on the LV.

I've done some tests with a file system on /dev/sda5 and the on
/dev/vg0/test (which is a LV on /dev/sda5) and I am really surprised:

First, I repeated my previous tests:

						         $dev

                                                /dev/sda5    /dev/vg0/test
---------------------------------------------+-------------+----------------
dd if=$dev of=/dev/null bs=512 count=1048576 |    71.2s    |   122.7s
dd if=$dev of=/dev/null bs=64k count=8192    |    71.5s    |    71.7s

Then I made a ext2 filesystem with 1K blocksize on /dev/sda5, mounted
it to /mnt, copied a 512MB random file to it, md5sum'med that fie and
dd'ed that file to /dev/null.  Then I recreated /dev/vg0/test and did
the same tests and that block device:

---------------------------------------------+-------------+----------------
cp -a /usr/local/foo /mnt                    |    96.6s    |   123.4s
md5sum /mnt/foo                              |    89.8s    |    92.4s
dd if=/mnt/bar of=/dev/null bs=512           |    71.8s    |    72.1s
dd if=/mnt/bar of=/dev/null bs=64k           |    71.7s    |    72.5s


When I use a 4K blocksize on the ext2 filesystem the times for
/dev/sda5 and /dev/vg0/test are even closer.

Result: Although the block device /dev/vg0/test is significantly
slower than /dev/sda5 (where /dev/vg0/test is located on /dev/sda5)
the *read* performance of the file system on top the block device is
roughly the same.  This is probably not some effect of buffer caching
since I did a blockdev --flushbufs $dev before each test, and
/usr/local/bar is 512MB in size which is twice as large as the main
memory size on that machine.

However, writing to an LV is still much slower than to a normal
partition.


urs

  reply	other threads:[~2001-05-26 11:17 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-02-26 15:44 [linux-lvm] LVM and *bad* performance (no striping) Urs Thuermann
2001-02-26 20:39 ` Joe Thornber
2001-02-26 21:03   ` Jorg de Jong
2001-02-26 21:38     ` Rik van Riel
2001-02-27  8:35   ` Patrick Caulfield
2001-02-27 12:21   ` Urs Thuermann
2001-02-28 11:05     ` Heinz J. Mauelshagen
2001-04-10 19:30       ` Urs Thuermann
2001-04-10 21:37         ` Andreas Dilger
2001-04-11 11:23           ` Urs Thuermann
2001-04-11 19:49             ` Andreas Dilger
2001-04-11 22:00               ` Terje Kvernes
2001-05-15 11:46               ` Urs Thuermann
2001-05-15 12:13                 ` Patrick Caulfield
2001-05-26 11:17                   ` Urs Thuermann [this message]
2001-05-27  7:47                     ` Andreas Dilger
2001-05-27  9:47                       ` Urs Thuermann
2001-05-27 17:01                       ` [linux-lvm] LVM and *bad* performance (counterexample) idsfa
2001-05-15 17:08                 ` [linux-lvm] LVM and *bad* performance (no striping) Andreas Dilger
2001-05-26 11:23                   ` Urs Thuermann
2001-02-26 21:41 ` Rik van Riel
2001-02-27 10:33   ` Urs Thuermann

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=m2ofsguzp5.fsf@isnogud.escape.de \
    --to=urs@isnogud.escape.de \
    --cc=linux-lvm@sistina.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.