From: Miquel van Smoorenburg <miquels@cistron.nl>
To: Andrew Morton <akpm@osdl.org>
Cc: linux-kernel@vger.kernel.org, linux-lvm@sistina.com
Subject: [linux-lvm] Re: 2.6.3-rc2-mm1 (dm)
Date: Fri Feb 13 09:11:24 2004 [thread overview]
Message-ID: <20040212203306.GA13192@cistron.nl> (raw)
In-Reply-To: <20040212015710.3b0dee67.akpm@osdl.org>
According to Andrew Morton:
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.3-rc2/2.6.3-rc2-mm1/
> +dm-01-export-dm_vcalloc.patch
> +dm-02-move-to_bytes-to_sectors.patch
> +dm-03-remove-dm_deferred_io.patch
> +dm-04-maintain-bio-ordering.patch
> +dm-05-alloc_dev-error-cleanup.patch
> +dm-07-dm_table_create-GFP-fix.patch
> +dm-08-zero-size-target-fix.patch
> +dm-09-dec_pending-locking-cleanup.patch
> +dm-10-drop-BIO_SEG_VALID.patch
The maintain-bio-ordering patch mostly fixes the performance problem
I was seeing on XFS-over-LVM-on-3ware-raid5. (See my earlier message
at http://www.ussg.iu.edu/hypermail/linux/kernel/0312.3/0684.html )
Excellent!
However there's still one issue:
I created a LVM volume on /dev/sda2, called /dev/vg0/test. Then
I created and mounted an XFS partition on /dev/vg0/test. XFS uses
a 512 byte blocksize by default, but the underlying /dev/sda2
device had a soft blocksize of 4096 (default after boot is 1024,
but I had been mucking around with it so it got set to 4096).
As a result, I couldn't get more than 35 MB/sec write speed out
of XFS mounted on the LVM device.
I added this little patch:
--- drivers/md/dm-table.c.ORIG 2004-02-12 20:49:47.000000000 +0100
+++ drivers/md/dm-table.c 2004-02-12 20:56:59.000000000 +0100
@@ -361,7 +361,7 @@
blkdev_put(bdev, BDEV_RAW);
else {
d->bdev = bdev;
- set_blocksize(bdev, d->bdev->bd_block_size);
+ set_blocksize(bdev, 512);
}
return r;
}
This forces the underlying device(s) to a soft blocksize of 512. And
I had my 80 MB/sec write speed back !
I'm not sure if setting the blocksize of the underlying device
always to 512 is the right solution. I think that set_blocksize
for dm devices should also set the size for the underlying devices,
but that probably means adding an extra hook so that
set_blocksize can call bdev->bd_disk->fops->set_blocksize(bdev, size).
Which, in the case of dm, would basically call set_blocksize for the
underlying devices again.
Correct ?
Mike.
WARNING: multiple messages have this Message-ID (diff)
From: Miquel van Smoorenburg <miquels@cistron.nl>
To: Andrew Morton <akpm@osdl.org>
Cc: linux-kernel@vger.kernel.org, linux-lvm@sistina.com
Subject: Re: 2.6.3-rc2-mm1 (dm)
Date: Thu, 12 Feb 2004 21:33:07 +0100 [thread overview]
Message-ID: <20040212203306.GA13192@cistron.nl> (raw)
In-Reply-To: <20040212015710.3b0dee67.akpm@osdl.org>
According to Andrew Morton:
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.3-rc2/2.6.3-rc2-mm1/
> +dm-01-export-dm_vcalloc.patch
> +dm-02-move-to_bytes-to_sectors.patch
> +dm-03-remove-dm_deferred_io.patch
> +dm-04-maintain-bio-ordering.patch
> +dm-05-alloc_dev-error-cleanup.patch
> +dm-07-dm_table_create-GFP-fix.patch
> +dm-08-zero-size-target-fix.patch
> +dm-09-dec_pending-locking-cleanup.patch
> +dm-10-drop-BIO_SEG_VALID.patch
The maintain-bio-ordering patch mostly fixes the performance problem
I was seeing on XFS-over-LVM-on-3ware-raid5. (See my earlier message
at http://www.ussg.iu.edu/hypermail/linux/kernel/0312.3/0684.html )
Excellent!
However there's still one issue:
I created a LVM volume on /dev/sda2, called /dev/vg0/test. Then
I created and mounted an XFS partition on /dev/vg0/test. XFS uses
a 512 byte blocksize by default, but the underlying /dev/sda2
device had a soft blocksize of 4096 (default after boot is 1024,
but I had been mucking around with it so it got set to 4096).
As a result, I couldn't get more than 35 MB/sec write speed out
of XFS mounted on the LVM device.
I added this little patch:
--- drivers/md/dm-table.c.ORIG 2004-02-12 20:49:47.000000000 +0100
+++ drivers/md/dm-table.c 2004-02-12 20:56:59.000000000 +0100
@@ -361,7 +361,7 @@
blkdev_put(bdev, BDEV_RAW);
else {
d->bdev = bdev;
- set_blocksize(bdev, d->bdev->bd_block_size);
+ set_blocksize(bdev, 512);
}
return r;
}
This forces the underlying device(s) to a soft blocksize of 512. And
I had my 80 MB/sec write speed back !
I'm not sure if setting the blocksize of the underlying device
always to 512 is the right solution. I think that set_blocksize
for dm devices should also set the size for the underlying devices,
but that probably means adding an extra hook so that
set_blocksize can call bdev->bd_disk->fops->set_blocksize(bdev, size).
Which, in the case of dm, would basically call set_blocksize for the
underlying devices again.
Correct ?
Mike.
next prev parent reply other threads:[~2004-02-12 20:33 UTC|newest]
Thread overview: 55+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-02-12 9:57 2.6.3-rc2-mm1 Andrew Morton
2004-02-12 9:57 ` 2.6.3-rc2-mm1 Andrew Morton
2004-02-12 11:13 ` 2.6.3-rc2-mm1 Andrew Morton
2004-02-12 11:13 ` 2.6.3-rc2-mm1 Andrew Morton
2004-02-12 11:57 ` 2.6.3-rc2-mm1 Anton Blanchard
2004-02-12 11:57 ` 2.6.3-rc2-mm1 Anton Blanchard
2004-02-12 12:09 ` 2.6.3-rc2-mm1 Andrew Morton
2004-02-12 12:09 ` 2.6.3-rc2-mm1 Andrew Morton
2004-02-12 14:40 ` 2.6.3-rc2-mm1 Zwane Mwaikambo
2004-02-12 14:40 ` 2.6.3-rc2-mm1 Zwane Mwaikambo
2004-02-12 14:46 ` 2.6.3-rc2-mm1 Anton Blanchard
2004-02-12 14:46 ` 2.6.3-rc2-mm1 Anton Blanchard
2004-02-12 14:47 ` 2.6.3-rc2-mm1 Anton Blanchard
2004-02-12 14:47 ` 2.6.3-rc2-mm1 Anton Blanchard
2004-02-12 11:24 ` 2.6.3-rc2-mm1 Nick Piggin
2004-02-12 11:24 ` 2.6.3-rc2-mm1 Nick Piggin
2004-02-12 14:46 ` 2.6.3-rc2-mm1 Zwane Mwaikambo
2004-02-12 14:46 ` 2.6.3-rc2-mm1 Zwane Mwaikambo
2004-02-12 15:40 ` 2.6.3-rc2-mm1 Mark Haverkamp
2004-02-12 15:40 ` 2.6.3-rc2-mm1 Mark Haverkamp
2004-02-12 21:38 ` 2.6.3-rc2-mm1 Andrew Morton
2004-02-12 21:38 ` 2.6.3-rc2-mm1 Andrew Morton
2004-02-12 22:33 ` 2.6.3-rc2-mm1 Nick Piggin
2004-02-12 22:33 ` 2.6.3-rc2-mm1 Nick Piggin
2004-02-12 17:06 ` 2.6.3-rc2-mm1 (compile stats) John Cherry
2004-02-12 17:06 ` John Cherry
2004-02-12 18:43 ` 2.6.3-rc2-mm1 Alistair John Strachan
2004-02-12 18:43 ` 2.6.3-rc2-mm1 Alistair John Strachan
2004-02-12 20:33 ` Miquel van Smoorenburg [this message]
2004-02-13 9:11 ` [linux-lvm] Re: 2.6.3-rc2-mm1 (dm) Miquel van Smoorenburg
2004-02-12 21:28 ` Nathan Scott
2004-02-13 9:11 ` [linux-lvm] " Nathan Scott
2004-02-12 22:08 ` Miquel van Smoorenburg
2004-02-13 9:11 ` [linux-lvm] " Miquel van Smoorenburg
2004-02-12 22:34 ` Andrew Morton
2004-02-13 9:11 ` [linux-lvm] " Andrew Morton
2004-02-13 12:08 ` Miquel van Smoorenburg
2004-02-13 16:29 ` Miquel van Smoorenburg
2004-02-13 0:04 ` 2.6.3-rc2-mm1 Torrey Hoffman
2004-02-13 0:04 ` 2.6.3-rc2-mm1 Torrey Hoffman
2004-02-14 10:36 ` 2.6.3-rc2-mm1 Terje Kvernes
2004-02-14 10:36 ` 2.6.3-rc2-mm1 Terje Kvernes
2004-02-13 21:04 ` [PATCH 2.6.3-rc2-mm1] Daniel McNeil
2004-02-13 21:30 ` [PATCH 2.6.3-rc2-mm1] __block_write_full patch Daniel McNeil
2004-02-13 21:49 ` [PATCH 2.6.3-rc2-mm1] filemap_fdatawait patch Daniel McNeil
2004-02-13 22:38 ` [PATCH 2.6.3-rc2-mm1] __block_write_full patch Andrew Morton
2004-02-13 23:30 ` Daniel McNeil
2004-02-13 23:48 ` Andrew Morton
2004-02-14 0:02 ` Daniel McNeil
2004-02-18 1:02 ` [PATCH 2.6.3-rc2-mm1] address_space_serialize_writeback patch Daniel McNeil
2004-02-18 1:43 ` Andrew Morton
2004-02-18 1:47 ` Andrew Morton
2004-02-18 19:36 ` Daniel McNeil
2004-02-14 5:27 ` 2.6.3-rc2-mm1 Glenn Johnson
2004-02-14 5:27 ` 2.6.3-rc2-mm1 Glenn Johnson
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=20040212203306.GA13192@cistron.nl \
--to=miquels@cistron.nl \
--cc=akpm@osdl.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-lvm@redhat.com \
--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.