Hello,
We are just using v3 for quite a long time, very stable, performance
are not bad but like many others, want to explore if possible to have
a better throughput.
Seems that are not many benchmark in the web about v4 vs v3 for
performance, etc. Anyone mind sharing some experience? What are the
real advantages in using v4?
Thanks.
On Fri, Oct 03, 2008 at 12:49:50AM +0800, Roy M. wrote:
> Hello,
>
> We are just using v3 for quite a long time, very stable, performance
> are not bad but like many others, want to explore if possible to have
> a better throughput.
Raw throughput should be the same. And I think the little benchmarking
I've seen has found that to be true.
If you're just doing big I/O to a few files, that may be all you care
about. If you're doing something more complicated then the situation
isn't well understood yet.
> Seems that are not many benchmark in the web about v4 vs v3 for
> performance, etc. Anyone mind sharing some experience? What are the
> real advantages in using v4?
In theory: if you're doing file locking or reopening files a lot, then
you may see a benefit from v4 delegations (which permit the client in
some situations to do those operations without telling the server), and
I do recall seeing some improvements e.g. with kernel compiles (which
tend to reopen a small set of files frequently).
--b.
Hello,
On Fri, Oct 3, 2008 at 1:17 AM, J. Bruce Fields <[email protected]> wrote:
> On Fri, Oct 03, 2008 at 12:49:50AM +0800, Roy M. wrote:
>
> If you're just doing big I/O to a few files, that may be all you care
> about. If you're doing something more complicated then the situation
> isn't well understood yet.
>
Do you mean for few files with large size stored in NFS, then maybe
not benefit too much from NFS4, while if I have many files, need to
fetch to client in parallel and in high concurrency, then it might be
a good choice? (in fact, I also heard client side caching in v4 is
better)
Besides, can I say v4 is the recommended to be used in production right now?
Thanks.
J. Bruce Fields wrote:
Raw throughput should be the same. And I think the little benchmarking
I've seen has found that to be true.
Actually v4 is better on fast nets because you can make the iosize bigger.
Jim Rees wrote:
> J. Bruce Fields wrote:
>
> Raw throughput should be the same. And I think the little benchmarking
> I've seen has found that to be true.
>
> Actually v4 is better on fast nets because you can make the iosize bigger.
>
How is that? NFSv3 supports a 32 bit transfer size and runs over
TCP, just the same as NFSv4.
The benefits should come via the use of delegations to decrease
some latencies.
ps
On Fri, Oct 03, 2008 at 01:34:51AM +0800, Roy M. wrote:
> Hello,
>
> On Fri, Oct 3, 2008 at 1:17 AM, J. Bruce Fields <[email protected]> wrote:
> > On Fri, Oct 03, 2008 at 12:49:50AM +0800, Roy M. wrote:
> >
> > If you're just doing big I/O to a few files, that may be all you care
> > about. If you're doing something more complicated then the situation
> > isn't well understood yet.
> >
>
> Do you mean for few files with large size stored in NFS, then maybe
> not benefit too much from NFS4, while if I have many files, need to
> fetch to client in parallel and in high concurrency, then it might be
> a good choice? (in fact, I also heard client side caching in v4 is
> better)
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.)
--b.
>
>
> Besides, can I say v4 is the recommended to be used in production right now?
>
> Thanks.
Hello,
On Sat, Oct 4, 2008 at 5:52 AM, J. Bruce Fields <[email protected]> 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?
But I just wonder without reading the NFS server, how the consistency
was maintained...
Thanks.
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 <[email protected]> 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.
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 <[email protected]>:
> 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 <[email protected]> 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 [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
>
--
[http://www.posix.brte.com.br/blog]
--------==== pOSix rules ====-------