Messages in this thread | | | Subject | Re: 2.6.0 NFS-server low to 0 performance | From | Trond Myklebust <> | Date | Sat, 10 Jan 2004 09:30:28 -0500 |
| |
På lau , 10/01/2004 klokka 06:10, skreiv Guennadi Liakhovetski: > Yes. The reason for the problem seems to be the increased default size of > the transfer unit of NFS from 2.4 to 2.6. 8K under 2.4 was still ok, 16K > is too much - only the first 5 fragments pass fine, then data starts to > get lost. If it is a hardware limitation (not all platforms can manage > 16K), it should be probably set back to 8K. If the reason is that some > buffer size was not increased correspondingly, then this should be done.
No! People who have problems with the support for large rsize/wsize under UDP due to lost fragments can
a) Reduce r/wsize themselves using mount b) Use TCP instead
The correct solution to this problem is (b). I.e. we convert mount to use TCP as the default if it is available. That is consistent with what all other modern implementations do.
Changing a hard maximum on the server in order to fit the lowest common denominator client is simply wrong.
Cheers, Trond - 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/
| |