lkml.org 
[lkml]   [2004]   [May]   [7]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
Date
SubjectRe: PATCH [NFSd] NFSv3/TCP
On Friday May 7, tennert@science-computing.de wrote:
> Hi Neil (and others),
>
> is there any reason why current 2.4 kernels do not allow for
> NFSSVC_MAXBLKSIZE to become as large as 32k?

Yes.
At server thread creation, you need to be able to
kmalloc(NFSSVC_MAXBLKSIZE+1024)
(or close to that) once per thread. On most architectures this is a
high-order alloc_pages and can often fail.
Also, on every UDP write request, the server needs to 'kmalloc' a buffer
to hold the whole request (actually on every request that is
fragmented, but write is most common). On most architectures, this
kmalloc will again require allocative several contiguous pages, which
can fail.

So this patch is only safe if you have a large-patch arch or only use
NFS over TCP.

There was once a patch floating around which allowed a larger
NFSSVC_MAXBLKSIZE on architectures with large page sizes, but it never
got properly submitted I think.


>
> The problem is when I use NFSv3/TCP with a 2.4.25, say, on the server
> side, as well as on the client side, I am experiencing lockups when
> copying medium-sized or large files from the NFS fs to a local fs.

There must be some other cause. Increasing the NFSSVC_MAXBLKSIZE is
just hiding a real problem I suspect.

NeilBrown
-
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-03-22 14:02    [W:0.033 / U:2.068 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site