From: "Roger Pau Monné" <roger.pau@citrix.com>
To: Stefan Bader <stefan.bader@canonical.com>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [PATCH] xen-blk(front|back): Handle large physical sector disks
Date: Tue, 14 May 2013 16:49:48 +0200 [thread overview]
Message-ID: <51924F0C.3080006@citrix.com> (raw)
In-Reply-To: <5191272A.7070703@canonical.com>
On 13/05/13 19:47, Stefan Bader wrote:
> I accidentally realized today that any domU's using the paravirt disk driver
> potentially suffer from poor performance when they get handed in a physical
> volume and partitioning is done inside the guest. The physical volume passed in
> has to be one that has the compat 512 logical sector size but hints its real
> sector size (eg. 4096) as physical sector size.
>
> In dom0 handling is correct and partitions or logical volumes there would be
> aligned to 4k. But the blkfront driver just gets one sector size (the logical)
> passed in from netback. And so inside the guest the drive appears to be an old
> style 512/512 drive. Alignment of partitions created in the guest very likely go
> wrong somewhere (they do for me).
>
> I tried to fix this in a way that works with all four combinations of dom0 and
> domU drivers. Tested those with a PVM guest that was set up to have a logical
> volume passed in as xvdb). Sidenote: PVM guests that map files or volume
> directly to partitions may be accidentally ok as ext4 uses 4k blocks by default).
>
> What I am not sure about is whether this also is sufficient for handling
> migration (possible to another host with other sectors). But I think that the
> units of tables is still 512, only alignment is changed. So it should more or
> less work.
>
> How does this look to you?
Thanks for the patch, apart from Jan's comment, it looks good to me. I
just have one question, if for example we are using iscsi disks, do
different initiators report different physical sector sizes for the same
disk?
I'm asking this because AFAICS blk_queue_physical_block_size will only
be set when the disk is first attached, but not when recovering from
migration, and if different initiators report different physical sector
sizes we should probably call blk_queue_physical_block_size with the new
value when recovering from migration.
next prev parent reply other threads:[~2013-05-14 14:49 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-05-13 17:47 [PATCH] xen-blk(front|back): Handle large physical sector disks Stefan Bader
2013-05-14 8:04 ` Jan Beulich
2013-05-15 9:26 ` Stefan Bader
2013-05-15 9:47 ` Jan Beulich
2013-05-15 10:04 ` James Harper
2013-05-15 10:10 ` Stefan Bader
2013-05-15 12:23 ` Jan Beulich
2013-05-15 13:54 ` Konrad Rzeszutek Wilk
2013-05-15 10:58 ` Stefan Bader
2013-05-15 12:28 ` Jan Beulich
2013-05-14 14:49 ` Roger Pau Monné [this message]
2013-05-14 16:11 ` Stefan Bader
2013-05-15 15:02 ` [PATCH v3] " Stefan Bader
2013-05-22 11:48 ` Stefan Bader
2013-05-22 12:21 ` Jan Beulich
2013-05-22 13:15 ` Stefan Bader
2013-05-22 13:22 ` Jan Beulich
2013-05-22 13:02 ` Konrad Rzeszutek Wilk
2013-05-28 12:47 ` Konrad Rzeszutek Wilk
2013-05-28 12:55 ` Stefan Bader
2013-05-28 16:17 ` Konrad Rzeszutek Wilk
2013-05-28 18:03 ` Stefan Bader
2013-06-05 20:25 ` Konrad Rzeszutek Wilk
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=51924F0C.3080006@citrix.com \
--to=roger.pau@citrix.com \
--cc=konrad.wilk@oracle.com \
--cc=stefan.bader@canonical.com \
--cc=xen-devel@lists.xensource.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.