Re: Is NFS v4 stable and recommend to use now?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



 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

[Index of Archives]     [Linux Filesystem Development]     [Linux USB Development]     [Linux Media Development]     [Video for Linux]     [Linux NILFS]     [Linux Audio Users]     [Yosemite Info]     [Linux SCSI]

  Powered by Linux