Actually, that is the reason why nfsv3 preformance does not scales increasing the client's memory. I did a lot of tests about that ( http://www.posix.brte.com.br/blog/?p=89 ), and the overhead of the protocol (to check the server informations about the file for consistency), was the nfsv3 stopper. But NFS is a protocol for sharing resources, and that is how it is supposed to work, no problem with that. I think NFSv4 is handling that problem with some kind of "delegation", where the client has "authority" on the filesystem or file.. so, working more or less like iscsi in this regard. Leal. 2008/10/4 J. Bruce Fields <bfields@xxxxxxxxxxxx>: > On Sat, Oct 04, 2008 at 09:34:49PM +0800, Roy M. wrote: >> Hello, >> >> On Sat, Oct 4, 2008 at 5:52 AM, J. Bruce Fields <bfields@xxxxxxxxxxxx> wrote: >> > I doubt the pattern of I/O really matters much--it's the opens and >> > closes themselves that matter. >> > >> > (In v3, close-to-open cache consistency requires that the client always >> > fetch file attributes from the server on an open. That means open() is >> > always going to take at least the ping time to the server. In v4 in >> > some situations the client can do the open with no call to the server at >> > all--by comparison such an open is almost instantaneous. If you're >> > doing a ton of opens all in a row, that may make a difference.) >> > >> >> In existing v3, you mean even if a file is cached locally by client, >> in each open, the file attributes need to be read from NFS server >> everytime? > > Right. The client has to do that to check whether someone else has > changed the file. See http://nfs.sourceforge.net/#faq_a8 for an > explanation of close-to-open cache consistency, which is what requires > this. > >> But I just wonder without reading the NFS server, how the consistency >> was maintained... > > I'm afraid I don't understand the question. > > --b. > -- > To unsubscribe from this list: send the line "unsubscribe linux-nfs" in > the body of a message to majordomo@xxxxxxxxxxxxxxx > More majordomo info at http://vger.kernel.org/majordomo-info.html > > -- [http://www.posix.brte.com.br/blog] --------==== pOSix rules ====------- -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
