Messages in this thread | | | Date | Sat, 10 Jan 2004 21:04:03 +0100 (CET) | From | Guennadi Liakhovetski <> | Subject | Re: 2.6.0 NFS-server low to 0 performance |
| |
On Sat, 10 Jan 2004, Trond Myklebust wrote:
> 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.
Not change - keep (from 2.4). You see, the problem might be - somebody updates the NFS-server from 2.4 to 2.6 and then suddenly some clients fail to work with it. Seems a non-obvious fact, that after upgrading the server clients' configuration might have to be changed. At the very least this must be documented in Kconfig.
Thanks Guennadi --- Guennadi Liakhovetski
- 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/
| |