[Qemu-devel] QEMU 9pfs intentionally returning short reads ?

[Qemu-devel] QEMU 9pfs intentionally returning short reads ?

[Daniel P. Berrange]

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.

Now this is allowed by POSIX, but in practice most filesystems will always
return the full amount of requested data for plain files, so this surprises
some (buggy) applications. In particular the 9pfs behaviour has broken Xorg's
xkbcomp program (well anything calling XrmGetFileDatabase) which results i
a non-functional keyboard for the guest X server. I filed a BZ against
libX11 to get this fixed:

  https://bugzilla.redhat.com/show_bug.cgi?id=712190

I'm wondering if this behaviour of QEMU is actually intentional though ?

This short read behaviour appears to be a result of this change from last
year:

  commit 5e94c103a0321ca47deb81643839c44a03047416
  Author: M. Mohan Kumar <mohan@in.ibm.com>
  Date:   Wed Jun 9 19:14:28 2010 +0530

    virtio-9p: Compute iounit based on host filesystem block size
    
    Compute iounit based on the host filesystem block size and pass it to
    client with open/create response. Also return iounit as statfs's f_bsize
    for optimal block size transfers.
    
    Signed-off-by: M. Mohan Kumar <mohan@in.ibm.com>
    Reviewd-by: Sripathi Kodi <sripathik@in.ibm.com>
    Signed-off-by: Venkateswararao Jujjuri <jvrao@linux.vnet.ibm.com>


Before that change, a read of 8192 bytes, returns 8192 bytes, after that
any read will return a max of 4096 bytes[1].

If this is intentional, then it is something for users/developers to
watch out for if running into wierd I/O errors with apps in QEMU guests
with 9pfs. It wouldn't surprise me if more apps were not correctly coping
with short reads on plain files.

Daniel

[1] It isn't strictly a 4096 byte limit. It is actually limited to the value
of the 'f_bsize' field of statfs() on the filesystem being passed through.
-- 
|: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org              -o-             http://virt-manager.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org       -o-       http://live.gnome.org/gtk-vnc :|

Re: [Qemu-devel] QEMU 9pfs intentionally returning short reads ?

[Aneesh Kumar K.V]

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

-aneesh

Re: [Qemu-devel] QEMU 9pfs intentionally returning short reads ?

[Daniel P. Berrange]

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

Regards,
Daniel
-- 
|: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org              -o-             http://virt-manager.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org       -o-       http://live.gnome.org/gtk-vnc :|

Re: [Qemu-devel] QEMU 9pfs intentionally returning short reads ?

[Venkateswararao Jujjuri]

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