From: Peter Staubach <staubach@redhat.com>
To: Trond Myklebust <trond.myklebust@fys.uio.no>
Cc: Kenny Simpson <theonetruekenny@yahoo.com>, linux-kernel@vger.kernel.org
Subject: Re: another nfs puzzle
Date: Wed, 07 Dec 2005 11:39:25 -0500 [thread overview]
Message-ID: <4397103D.7050409@redhat.com> (raw)
In-Reply-To: <1133971780.27373.64.camel@lade.trondhjem.org>
Trond Myklebust wrote:
>
>I agree. It is clearly going to be a drag on performance, but it should
>be very much a corner case, so...
>
>
>
Yes, file systems tend to mostly be about the corner cases though... :-)
>To tell you the truth, I'm more interested in this case in order to
>figure out how to make mmap() work correctly for the case of an ordinary
>file, but where the file changes on the server. Currently we just call
>invalidate_inode_pages2(), without unmapping first. The conclusion from
>Kenny's testcase appears to be that this may lead to mmapped dirty data
>being lost.
>
Ugly, huh? The options seem to be to either write out all of the data
to the server or just truncate it. I have seen the former used mostly,
although this does generate the "last one there wins" scenario. This
does match the usual semantics associated with normal cached data from
write(2)s and should fit well with the NFSv4 callback notifying that a
write delegation is being withdrawn.
Thanx...
ps
prev parent reply other threads:[~2005-12-07 16:39 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-12-06 22:04 another nfs puzzle Kenny Simpson
2005-12-07 3:24 ` Trond Myklebust
2005-12-07 14:50 ` Kenny Simpson
2005-12-07 14:01 ` Peter Staubach
2005-12-07 14:11 ` Trond Myklebust
2005-12-07 14:18 ` Peter Staubach
2005-12-07 14:34 ` Trond Myklebust
2005-12-07 15:34 ` Peter Staubach
2005-12-07 15:41 ` Trond Myklebust
2005-12-07 15:56 ` Peter Staubach
2005-12-07 16:09 ` Trond Myklebust
2005-12-07 16:39 ` Peter Staubach [this message]
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=4397103D.7050409@redhat.com \
--to=staubach@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=theonetruekenny@yahoo.com \
--cc=trond.myklebust@fys.uio.no \
/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