From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:51949) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W1fhJ-00055f-3j for qemu-devel@nongnu.org; Fri, 10 Jan 2014 12:16:42 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1W1fhI-00008B-2a for qemu-devel@nongnu.org; Fri, 10 Jan 2014 12:16:41 -0500 Received: from mail-pb0-x229.google.com ([2607:f8b0:400e:c01::229]:43944) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W1fhH-00007s-Qa for qemu-devel@nongnu.org; Fri, 10 Jan 2014 12:16:40 -0500 Received: by mail-pb0-f41.google.com with SMTP id jt11so4696600pbb.14 for ; Fri, 10 Jan 2014 09:16:39 -0800 (PST) MIME-Version: 1.0 In-Reply-To: <52D01B8D.6080100@kamp.de> References: <1388062130-21126-1-git-send-email-pl@kamp.de> <20140109141322.GB2862@dhcp-200-207.str.redhat.com> <52CEC998.4040409@kamp.de> <20140110114042.GB4276@dhcp-200-207.str.redhat.com> <52CFE396.7070802@kamp.de> <52CFE7C9.9060805@redhat.com> <52D00C4A.6010907@kamp.de> <20140110154614.GE4276@dhcp-200-207.str.redhat.com> <52D01B8D.6080100@kamp.de> Date: Fri, 10 Jan 2014 09:16:38 -0800 Message-ID: From: ronnie sahlberg Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: [Qemu-devel] [PATCHv5] block: add native support for NFS List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Peter Lieven Cc: Kevin Wolf , "famz@redhat.com" , qemu-devel , Orit Wasserman , Stefan Hajnoczi , Paolo Bonzini On Fri, Jan 10, 2014 at 8:10 AM, Peter Lieven wrote: > > Ronnie, can you also give a short advise on Kevin's question about short reads. > I think they can happen if we read beyond past EOF or not? > Short reads should normally not happen in libnfs itself since servers are often careful always trying to sending back as much data as the client requested. There is a common exception though, for the case where you read past the end of file. So short reads should normally not happen. Unless QEMU or the guest sends a request to libnfs to read past the end of the file. If you send a READ for 1024 bytes to an nfs server at the offset 512 bytes from the end-of-file then the server will respond with a read reply containing 512 bytes of data (and the eof flag set in the reply). In my experience, most kernel/os based clients seem to be very careful to never try to read beyond enf of file, so this rarely happens in normal nfs. (I only recall HPUX being a system where it would be common to always issue nfs i/o in multiples of 4k so for those clients it was very important to make sure you implement short reads correctly in the server). I don't know how careful QEMU is in trying to prevent reading past the end of the device or if it enforces it if the guest tries. It is probably worth checking for short reads, at least for the case where you might be reading past end of file.