Re: PATCH [NFSd] NFSv3/TCP

[Oliver Tennert]

On Fri, 7 May 2004, Neil Brown wrote:

> On Friday May 7, tennert@xxxxxxxxxxxxxxxxxxxx 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.

So isn't it unsafe either with the NFSSVC_MAXBLKSIZE set to the original
8k? Or is it just less unsafe, then?

Anyway, I assure you the lockups occurred exactly when
server-side NFSv3/TCP got into the vanilla kernel at 2.4.19, and the only
significant difference I could see was this. I always used NFSv3/TCP
before then, and had no problems whatsoever. After that, I had to switch
to UDP.


>
> 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.
>

If only the coincidence was not so clear.

Best regards and thanks

Oliver

__
________________________________________creating IT solutions

Dr. Oliver Tennert			science + computing ag
phone   +49(0)7071 9457-598		Hagellocher Weg 71-75
fax     +49(0)7071 9457-411		D-72070 Tuebingen, Germany
O.Tennert@xxxxxxxxxxxxxxxxxxxx		www.science-computing.de



-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/