All of lore.kernel.org
 help / color / mirror / Atom feed
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

      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.