From: Venkateswararao Jujjuri <jvrao@linux.vnet.ibm.com>
To: qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] QEMU 9pfs intentionally returning short reads ?
Date: Fri, 10 Jun 2011 08:29:14 -0700 [thread overview]
Message-ID: <4DF2384A.8020105@linux.vnet.ibm.com> (raw)
In-Reply-To: <20110610122025.GE18497@redhat.com>
On 06/10/2011 05:20 AM, Daniel P. Berrange wrote:
> On Fri, Jun 10, 2011 at 05:36:13PM +0530, Aneesh Kumar K.V wrote:
>> On Fri, 10 Jun 2011 11:33:05 +0100, "Daniel P. Berrange"<berrange@redhat.com> wrote:
>>> I've been doing some work trying to run QEMU guests with a root filesystem
>>> exported from the host using virtio 9pfs. One of the issues that I have
>>> discovered is that the 9p FS running on QEMU appears to cap all reads at
>>> 4096 bytes[1]. Any larger read will return only partial data for plain
>>> files.
>>>
>> But we should loop in kernel, requesting for multiple 9p request.
>>
>> kernel does
>>
>> size = fid->iounit ? fid->iounit : fid->clnt->msize - P9_IOHDRSZ;
>> if (count> size)
>> ret = v9fs_file_readn(filp, NULL, udata, count, *offset);
>> else
>> ret = p9_client_read(fid, NULL, udata, *offset, count);
>>
>> and v9fs_file_readn() does..
>>
>> do {
>> n = p9_client_read(fid, data, udata, offset, count);
>> if (n<= 0)
>> break;
>>
>> if (data)
>> data += n;
>> if (udata)
>> udata += n;
>>
>> offset += n;
>> count -= n;
>> total += n;
>> } while (count> 0&& n == size);
>>
>>
>> I also did an strace of simple test and i see
>>
>> open("test", O_RDONLY) = 3
>> read(3, "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 8192) = 8192
> In my test I did
>
> # strace -e trace=read,open perl -e 'open FOO, "/usr/share/X11/XKeysymDB"; sysread FOO, $foo, 8192'
> open("/usr/share/X11/XKeysymDB", O_RDONLY) = 3
> read(3, "! Copyright 1993 Massachusetts I"..., 8192) = 4096
>
> Perhaps there is a guest kernel driver difference ? I'm using
>
> 2.6.35.13-91.fc14.x86_64
The default msize is 8k; Because of iounit the net layer need to send
the IO in the chunks of 4k
8k - header size faults into 4k; But never the less the fs layer should
loop.
There was an issue with read; and that bug is fixed by
commit 97e8442b0971ea6be9a495b3d03402985cfe5d6a
Author: M. Mohan Kumar <mohan@in.ibm.com>
Date: Fri Jun 4 11:59:07 2010 +0000
9p: Make use of iounit for read/write
Change the v9fs_file_readn function to limit the maximum transfer size
based on the iounit or msize.
Also remove the redundant check for limiting the transfer size in
v9fs_file_write. This check is done by p9_client_write.
Signed-off-by: M. Mohan Kumar <mohan@in.ibm.com>
Signed-off-by: Eric Van Hensbergen <ericvh@gmail.com>
Thanks,
JV
> Regards,
> Daniel
prev parent reply other threads:[~2011-06-10 15:29 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-06-10 10:33 [Qemu-devel] QEMU 9pfs intentionally returning short reads ? Daniel P. Berrange
2011-06-10 12:06 ` Aneesh Kumar K.V
2011-06-10 12:20 ` Daniel P. Berrange
2011-06-10 15:29 ` Venkateswararao Jujjuri [this message]
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=4DF2384A.8020105@linux.vnet.ibm.com \
--to=jvrao@linux.vnet.ibm.com \
--cc=qemu-devel@nongnu.org \
/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.