Return-Path: linux-nfs-owner@vger.kernel.org Received: from mx1.redhat.com ([209.132.183.28]:37975 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752001AbbB0BtM (ORCPT ); Thu, 26 Feb 2015 20:49:12 -0500 Message-ID: <1425001738.21632.45.camel@redhat.com> Subject: Re: File Read Returns Non-existent Null Bytes From: Harshula To: Chris Perl Cc: Simo Sorce , Trond Myklebust , Linux NFS Mailing List , Chris Perl , juzou@redhat.com Date: Fri, 27 Feb 2015 12:48:58 +1100 In-Reply-To: References: <1424964150.13431.57.camel@willson.usersys.redhat.com> <1424964871.10136.6.camel@primarydata.com> <1424964994.640.0.camel@willson.usersys.redhat.com> Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Sender: linux-nfs-owner@vger.kernel.org List-ID: Hi Chris, On Thu, 2015-02-26 at 10:45 -0500, Chris Perl wrote: > > Ok, I assume proper use of locking will address the situation and allow > > readers to get consistent data and not null bytes ? > > Yes, trond said this explicitly in one of his earlier replies. You may want to double check by modifying your reproducer to use locking. Just want to clarify that your example is of a writer appending to a file while a reader keeps trying to read upto the EOF. If so, what's happening is that the metadata (file size) becomes out of sync with actual file data requested from the NFS server due to post-op attr attached to the READ reply containing an updated (increased) file size. Then NULLs are introduced between the actual file data received and the new increased file size. This is then presented to user space. Before the synchronous READ path was removed from the NFS client code, this issue could be avoided by using the "sync" NFS mount option. cya, #