From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:47494) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QUz1b-0001wX-KC for qemu-devel@nongnu.org; Fri, 10 Jun 2011 06:33:12 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QUz1a-0007Yk-Ap for qemu-devel@nongnu.org; Fri, 10 Jun 2011 06:33:11 -0400 Received: from mx1.redhat.com ([209.132.183.28]:57383) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QUz1Z-0007YI-Vj for qemu-devel@nongnu.org; Fri, 10 Jun 2011 06:33:10 -0400 Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id p5AAX8GP016420 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Fri, 10 Jun 2011 06:33:08 -0400 Received: from redhat.com (dhcp-1-188.lcy.redhat.com [10.32.224.188]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id p5AAX5WN015845 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO) for ; Fri, 10 Jun 2011 06:33:07 -0400 Date: Fri, 10 Jun 2011 11:33:05 +0100 From: "Daniel P. Berrange" Message-ID: <20110610103305.GD18497@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Subject: [Qemu-devel] QEMU 9pfs intentionally returning short reads ? Reply-To: "Daniel P. Berrange" List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org 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 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 Reviewd-by: Sripathi Kodi Signed-off-by: Venkateswararao Jujjuri 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 :|