Messages in this thread | | | From | Neil Brown <> | Date | Fri, 7 May 2004 16:47:56 +1000 | Subject | Re: 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/
| |