From: Heinz Graalfs <graalfs@linux.vnet.ibm.com>
To: Kevin Wolf <kwolf@redhat.com>
Cc: Christian Borntraeger <borntraeger@de.ibm.com>,
jfrei@linux.vnet.ibm.com, qemu-devel@nongnu.org,
Stefan Hajnoczi <stefanha@redhat.com>,
agraf@suse.de
Subject: Re: [Qemu-devel] [PATCH/RFC] block: Ensure that block size constraints are considered
Date: Tue, 11 Dec 2012 10:58:12 +0100 [thread overview]
Message-ID: <1355219892.4245.14.camel@br8hfpp0.de.ibm.com> (raw)
In-Reply-To: <50C5A37F.9020300@redhat.com>
Hi Kevin,
I'm using the bdrv_pread() function during boot partition detection ...
In detail:
bdrv_pread() is called to read 32 bytes from a 2048 bytes formatted
disk. This results in setting up a read of 512 bytes (1 sector
multiplied by 512 current code in paio_submit()), which is wrong for a
O_DIRECT opened file, and produces the error.
Heinz
On Mon, 2012-12-10 at 09:55 +0100, Kevin Wolf wrote:
> Am 07.12.2012 21:26, schrieb Heinz Graalfs:
> > Hello Kevin,
> >
> > I'm resending my answer as of Nov 23rd.
> >
> > Is this still on your queue?
>
> No, it wasn't. I guess I was waiting for a new version of the patch.
>
> >>> }
> >>>
> >>> void *qemu_blockalign(BlockDriverState *bs, size_t size)
> >>> diff --git a/block/raw-posix.c b/block/raw-posix.c
> >>> index f2f0404..baebf1d 100644
> >>> --- a/block/raw-posix.c
> >>> +++ b/block/raw-posix.c
> >>> @@ -700,6 +700,12 @@ static BlockDriverAIOCB *paio_submit(BlockDriverState *bs, int fd,
> >>> acb->aio_nbytes = nb_sectors * 512;
> >>> acb->aio_offset = sector_num * 512;
> >>>
> >>> + /* O_DIRECT also requires an aligned length */
> >>> + if (bs->open_flags & BDRV_O_NOCACHE) {
> >>> + acb->aio_nbytes += acb->bs->buffer_alignment - 1;
> >>> + acb->aio_nbytes &= ~(acb->bs->buffer_alignment - 1);
> >>> + }
> >>
> >> Modifying aio_nbytes, but not the iov looks wrong to me. This may work
> >> in the handle_aiocb_rw_linear() code path, but not with actual vectored I/O.
> >
> > Current coding ensures that read IO buffers always seem to be aligned
> > correctly. Whereas read length values are not always appropriate for an
> > O_DIRECT scenario.
> >
> > For a 2048 formatted disk I verified that
> >
> > 1. non vectored IO - the length needs to be adapted several times,
> > which is accomplished now by the patch.
> >
> > 2. vectored IO - the qiov's total length is always a multiple of the
> > logical block size
> > (which is also verified in virtio_blk_handle_read())
> > The particular iov length fields are already correctly setup as a
> > multiple of the logical block size when processed in
> > virtio_blk_handle_request().
>
> I must admit that I don't quite understand this. As far as I know,
> virtio-blk doesn't make any difference between requests with niov = 1
> and real vectored requests. So how can the length of the latter always
> be right, whereas the length of the former may be wrong?
>
> The other point is that requests may not even be coming from virtio-blk.
> They could be made by other device emulations or they could come from a
> block job. (They also could be the result of a merge in the block layer,
> though if the original requests were aligned, the result will stay aligned)
>
> Kevin
>
next prev parent reply other threads:[~2012-12-11 9:58 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-11-21 8:58 [Qemu-devel] [PATCH/RFC] block: Ensure that block size constraints are considered Christian Borntraeger
2012-11-21 9:15 ` Kevin Wolf
2012-11-21 10:00 ` Christian Borntraeger
2012-11-21 11:24 ` Heinz Graalfs
2012-11-21 16:03 ` Paolo Bonzini
2012-11-22 12:03 ` Christian Borntraeger
2012-11-23 10:45 ` Heinz Graalfs
2012-12-07 20:26 ` Heinz Graalfs
2012-12-10 8:55 ` Kevin Wolf
2012-12-11 9:58 ` Heinz Graalfs [this message]
2012-12-11 10:30 ` Kevin Wolf
2012-12-11 13:53 ` Heinz Graalfs
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=1355219892.4245.14.camel@br8hfpp0.de.ibm.com \
--to=graalfs@linux.vnet.ibm.com \
--cc=agraf@suse.de \
--cc=borntraeger@de.ibm.com \
--cc=jfrei@linux.vnet.ibm.com \
--cc=kwolf@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=stefanha@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).