2009-04-17 18:46:50

by J. Bruce Fields

[permalink] [raw]
Subject: Re: [PATCH 0/11] nfsd: Summary of "Improve NFS server performance"

On Wed, Mar 25, 2009 at 07:06:07PM +0530, Krishna Kumar wrote:
> From: Krishna Kumar <[email protected]>
>
> Patch summary:
> --------------
> Change the caching from ino/dev to a file handle model. Advantages:
>
> 1. Since file handles are unique, this patch removes all dependencies on the
> kernel readahead parameters and it's implementation; and instead caches
> files based on file handles.
> 2. Allows the server to not have to open/close a file multiple times when the
> client reads it, and results in faster lookup times.
> 3. Readahead is automatically taken care of since the file is not closed while
> it is getting read (quickly) by the client.
> 4. Another optimization is to avoid getting the cache lock twice for each read
> operation (after the first time it is taken to update the cache).
> 5. (ra_size, ra_depth retain the "ra" prefix for now, since I have not checked
> whether changing that will break any user programs)

You're referring here to the "ra" line in /proc/net/rpc/nfsd?

--b.


2009-04-17 19:31:11

by Krishna Kumar2

[permalink] [raw]
Subject: Re: [PATCH 0/11] nfsd: Summary of "Improve NFS server performance"

"J. Bruce Fields" <[email protected]> wrote on 04/18/2009 12:16:47 AM:

> Re: [PATCH 0/11] nfsd: Summary of "Improve NFS server performance"
>
> On Wed, Mar 25, 2009 at 07:06:07PM +0530, Krishna Kumar wrote:
> > From: Krishna Kumar <[email protected]>
> >
> > Patch summary:
> > --------------
> > Change the caching from ino/dev to a file handle model. Advantages:
> >
> > 1. Since file handles are unique, this patch removes all dependencies
on the
> > kernel readahead parameters and it's implementation; and instead
caches> > files based on file handles.
> > 2. Allows the server to not have to open/close a file multiple times
when the
> > client reads it, and results in faster lookup times.
> > 3. Readahead is automatically taken care of since the file is not
closed while
> > it is getting read (quickly) by the client.
> > 4. Another optimization is to avoid getting the cache lock twice for
each read
> > operation (after the first time it is taken to update the cache).
> > 5. (ra_size, ra_depth retain the "ra" prefix for now, since I have not
checked
> > whether changing that will break any user programs)
>
> You're referring here to the "ra" line in /proc/net/rpc/nfsd?

Yes - at that time I was thinking of any consumer of this file. From your
comment,
I see that it is not an issue now, thanks for pointing it out.

Thanks,

- KK