From: "J. Bruce Fields" <bfields@fieldses.org>
To: Chuck Lever <chuck.lever@oracle.com>
Cc: Chris Perl <cperl@janestreet.com>,
Trond Myklebust <trond.myklebust@primarydata.com>,
Linux NFS Mailing List <linux-nfs@vger.kernel.org>,
Chris Perl <chris.perl@gmail.com>
Subject: Re: File Read Returns Non-existent Null Bytes
Date: Mon, 2 Mar 2015 15:58:50 -0500 [thread overview]
Message-ID: <20150302205850.GG8033@fieldses.org> (raw)
In-Reply-To: <DCF31069-FEF7-4DD8-9FD0-575262181A43@oracle.com>
On Mon, Mar 02, 2015 at 10:57:43AM -0500, Chuck Lever wrote:
> Hi Chris!
>
> Still in the context of deciding what should go in the FAQ, my
> comments are below.
>
>
> On Mar 2, 2015, at 10:19 AM, Chris Perl <cperl@janestreet.com> wrote:
>
> >> I’m in favor of staying more hand-wavy. Otherwise you will end up
> >> making promises you don’t intend to keep ;-)
> >
> > FWIW, I'm in favor of at least some specifics. Something stating that
> > the results of reading from a file while another client holds it open
> > for write are undefined (point 3 of what was already proposed).
>
> The language has to be very careful.
>
> Opens for write are used frequently and by themselves do not cause
> any damage. Corruption risk increases when actual writes occur,
> followed by reads of the same file on other clients, without a
> close and re-open.
>
> Also, any published statement about this could lock us into a
> particular behavior. That makes it harder to improve or change
> (say, to address a bug) in the future.
>
> Specifics can be discussed on the mailing list on a case-by-case
> basis. The specifics depend on a bunch of things, for example:
>
> - which clients are in play
> - which NFS version is in use (delegations and open state)
> - whether reading and writing is in the same byte range
> - whether the file size is changing
> - whether O_DIRECT and mapped files are in use
These are cases we'd only need to go into if we wanted to give
*stronger* gaurantees than "all bets are off when you don't serialize
with write opens", yes?
And, sure, that would be interesting, but I think Chris is just asking
for a clearer statement of that basic requirement.
He's far from the first to assume that the results you'd get from
overlapping opens would be out of date but still reasonable in some
sense, and the FAQ could use a stronger statement that that's not the
case.
--b.
>
> And so on. There could also be real bugs, which would become
> apparent after discussion.
>
> A general (and more explicit) warning about write sharing is
> appropriate to add. I feel it would be difficult to get the
> specifics right.
>
> I could add something to A8 that says “Detailed questions can be
> directed to linux-nfs@vger.kernel.org.” Do you feel you got a good
> answer from the mailing list?
>
> --
> Chuck Lever
> chuck[dot]lever[at]oracle[dot]com
>
>
next prev parent reply other threads:[~2015-03-02 20:58 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
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 [this message]
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=20150302205850.GG8033@fieldses.org \
--to=bfields@fieldses.org \
--cc=chris.perl@gmail.com \
--cc=chuck.lever@oracle.com \
--cc=cperl@janestreet.com \
--cc=linux-nfs@vger.kernel.org \
--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