All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mike Snitzer <snitzer@redhat.com>
To: device-mapper development <dm-devel@redhat.com>
Subject: Re: dm-multipath splitting IOs in 4k blocks
Date: Fri, 22 Jan 2010 14:14:56 -0500	[thread overview]
Message-ID: <20100122191455.GA30971@redhat.com> (raw)
In-Reply-To: <20100122164109.GA15636@marmite.ath.cx>

On Fri, Jan 22 2010 at 11:41am -0500,
Bob <M8R-0t7cpu@mailinator.com> wrote:

> Hello,
> 
> I have a question about dm-multipath. As you can see below, it seems that
> multipath splits any IO incoming to the device in 4k blocks, and then
> reassembles it when doing the actual read from the SAN. If the device is opened
> in direct IO mode, this behavior is not experienced. It is not experienced
> either if the IO is sent directly to a single path (eg /dev/sdef in this
> example).
> 
> My question is : what causes this behavior, and is there any way to change that ?

direct-io will cause DM to accumulate pages into larger bios (via
bio_add_page calls to dm_merge_bvec).  This is why you see larger
requests with iflag=direct.

Buffered IO writes (from the page-cache) will always be in one-page
units.  It is the IO scheduler that will merge these requests.

Buffered IO reads _should_ have larger requests.  So it is curious that
you're seeing single-page read requests.  I can't reproduce that on a
recent kernel.org kernel.  Will need time to test on RHEL 5.3.

NOTE: all DM devices should behave like I explained above (you just
happen to be focusing on dm-multipath).  Testing against normal "linear"
DM devices would also be valid.

> Some quick dd tests would tend to show that the device is quite faster if
> multipath doesn't split the IOs.

The testing output you provided doesn't reflect that (nor would I expect
it to for sequential IO if readahead is configured)...

Mike

> [root@test-bis ~]# dd if=/dev/dm-5 of=/dev/null bs=16384
> 
> Meanwhile...
> 
> [root@test-bis ~]# iostat -kx /dev/dm-5 /dev/sdef /dev/sdfh /dev/sdgi /dev/sdgw 5
> ...
> Device:         rrqm/s   wrqm/s   r/s   w/s    rkB/s    wkB/s avgrq-sz avgqu-sz   await  svctm  %util
> sdef           4187.82     0.00 289.42  0.00 17932.14     0.00   123.92     0.45    1.56   1.01  29.34
> sdfh           4196.41     0.00 293.81  0.00 17985.63     0.00   122.43     0.41    1.39   0.90  26.37
> sdgi           4209.98     0.00 286.43  0.00 17964.07     0.00   125.44     0.69    2.38   1.43  40.98
> sdgw           4188.62     0.00 289.22  0.00 17885.03     0.00   123.68     0.54    1.87   1.16  33.59
> dm-5              0.00     0.00 17922.55  0.00 71690.22     0.00     8.00    47.14    2.63   0.05  98.28
> 
> => avgrq-sz is 4kB (8.00 blocks) on the mpath device
> --------
> [root@test-bis ~]# dd if=/dev/dm-5 iflag=direct of=/dev/null bs=16384
> 
> iostat now gives :
> Device:         rrqm/s   wrqm/s   r/s   w/s    rkB/s    wkB/s avgrq-sz avgqu-sz   await  svctm  %util
> sdef              0.00     0.00 640.00  0.00 10240.00     0.00    32.00     0.31    0.48   0.48  30.86
> sdfh              0.00     0.00 644.40  0.00 10310.40     0.00    32.00     0.22    0.34   0.34  22.10
> sdgi              0.00     0.00 663.80  0.00 10620.80     0.00    32.00     0.24    0.36   0.36  24.20
> sdgw              0.00     0.00 640.00  0.00 10240.00     0.00    32.00     0.20    0.32   0.32  20.28
> dm-5              0.00     0.00 2587.00  0.00 41392.00     0.00    32.00     0.97    0.38   0.38  97.20
> 
> => avgrq-sz is now 16kB (32.00 blocks) on the mpath device

  reply	other threads:[~2010-01-22 19:14 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-01-22 16:41 dm-multipath splitting IOs in 4k blocks Bob
2010-01-22 19:14 ` Mike Snitzer [this message]
  -- strict thread matches above, loose matches on Subject: below --
2010-01-28 16:24 Bob
2010-01-22 13:52 Bob

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=20100122191455.GA30971@redhat.com \
    --to=snitzer@redhat.com \
    --cc=dm-devel@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.