All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Daniel P. Berrange" <berrange@redhat.com>
To: qemu-devel@nongnu.org
Subject: [Qemu-devel] QEMU 9pfs intentionally returning short reads ?
Date: Fri, 10 Jun 2011 11:33:05 +0100	[thread overview]
Message-ID: <20110610103305.GD18497@redhat.com> (raw)

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 :|

             reply	other threads:[~2011-06-10 10:33 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-06-10 10:33 Daniel P. Berrange [this message]
2011-06-10 12:06 ` [Qemu-devel] QEMU 9pfs intentionally returning short reads ? Aneesh Kumar K.V
2011-06-10 12:20   ` Daniel P. Berrange
2011-06-10 15:29     ` Venkateswararao Jujjuri

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=20110610103305.GD18497@redhat.com \
    --to=berrange@redhat.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.