From: Harshula <harshula@redhat.com>
To: Chris Perl <cperl@janestreet.com>
Cc: Simo Sorce <simo@redhat.com>,
Trond Myklebust <trond.myklebust@primarydata.com>,
Linux NFS Mailing List <linux-nfs@vger.kernel.org>,
Chris Perl <chris.perl@gmail.com>,
juzou@redhat.com
Subject: Re: File Read Returns Non-existent Null Bytes
Date: Fri, 27 Feb 2015 12:48:58 +1100 [thread overview]
Message-ID: <1425001738.21632.45.camel@redhat.com> (raw)
In-Reply-To: <CAAih9mgZ5OwWr6Vw1UTGD=Fd6ASyhoifSOVjd7cDjwXxWbftTQ@mail.gmail.com>
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,
#
next prev parent reply other threads:[~2015-02-27 1:49 UTC|newest]
Thread overview: 44+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-02-23 20:56 File Read Returns Non-existent Null Bytes Chris Perl
2015-02-23 22:34 ` Trond Myklebust
2015-02-25 17:04 ` Chris Perl
2015-02-25 17:37 ` Trond Myklebust
2015-02-25 21:02 ` Chris Perl
2015-02-25 21:47 ` Trond Myklebust
2015-02-25 21:53 ` Chris Perl
2015-02-25 22:15 ` Trond Myklebust
2015-02-26 12:41 ` Chris Perl
2015-02-26 13:29 ` Trond Myklebust
2015-02-26 13:42 ` Chris Perl
2015-02-26 14:10 ` Chris Perl
2015-02-26 15:22 ` Simo Sorce
2015-02-26 15:34 ` Trond Myklebust
2015-02-26 15:36 ` Simo Sorce
2015-02-26 15:45 ` Chris Perl
2015-02-26 15:56 ` Simo Sorce
2015-02-27 1:48 ` Harshula [this message]
2015-02-27 13:17 ` Chris Perl
2015-02-26 16:00 ` Chris Perl
2015-02-26 23:43 ` Trond Myklebust
2015-02-26 15:37 ` Trond Myklebust
2015-02-27 22:40 ` J. Bruce Fields
2015-02-27 23:33 ` Chuck Lever
2015-03-02 15:19 ` Chris Perl
2015-03-02 15:57 ` Chuck Lever
2015-03-02 20:58 ` J. Bruce Fields
2015-03-02 21:15 ` Chuck Lever
2015-03-03 13:29 ` Chris Perl
2015-03-03 15:30 ` Chuck Lever
2015-03-03 17:44 ` Trond Myklebust
2015-03-03 19:57 ` Chuck Lever
2015-03-02 21:33 ` didier
2015-03-03 9:09 ` Boaz Harrosh
[not found] ` <CAHHaOubVomDJ5uePb7DFGizZ0TBsyC-tJN5p6-RWOYKQC2oxvA@mail.gmail.com>
2015-02-27 20:13 ` Chris Perl
2015-02-25 22:32 ` Chuck Lever
2015-02-26 0:37 ` Trond Myklebust
2015-02-26 0:43 ` Trond Myklebust
2015-02-26 1:27 ` Trond Myklebust
2015-02-26 15:08 ` Chuck Lever
2015-02-26 16:26 ` fsx size error (was: File Read Returns Non-existent Null Bytes) Chuck Lever
2015-02-26 17:27 ` Trond Myklebust
2015-02-26 19:00 ` Chuck Lever
2015-02-26 23:06 ` Trond Myklebust
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=1425001738.21632.45.camel@redhat.com \
--to=harshula@redhat.com \
--cc=chris.perl@gmail.com \
--cc=cperl@janestreet.com \
--cc=juzou@redhat.com \
--cc=linux-nfs@vger.kernel.org \
--cc=simo@redhat.com \
--cc=trond.myklebust@primarydata.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox