lkml.org 
[lkml]   [2005]   [Dec]   [7]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: another nfs puzzle
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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-12-07 17:42    [W:0.097 / U:0.124 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site